Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discovery port changed after starting geth #29359

Open
amplicity opened this issue Mar 27, 2024 · 3 comments
Open

Discovery port changed after starting geth #29359

amplicity opened this issue Mar 27, 2024 · 3 comments
Labels

Comments

@amplicity
Copy link

amplicity commented Mar 27, 2024

System information

Geth version: 1.13.14
CL client & version: prysm@5.0.1
OS & Version: Ubuntu 23.04
Other: Using UFW, confirmed TCP ports (30303) are open via canyouseeme.

Expected behaviour

Discovery and listener port should be as I configured them via options, or the default (30303).

Actual behaviour

Discovery port starts out as default or configured value via options, but then changes. I see a "New local node record" shortly after a previous "New local node record" which shows the tcp/udp how I configured, and then the udp becomes an erroneous port.

Steps to reproduce the behaviour

Start geth with no options or --port and --discovery.port. In geth attach, run admin.nodeInfo in the next few hours. The discovery port will eventually change and be different. The time to change ranged from nearly instantly after startup, to a few hours after configuration.

Backtrace

I've compiled a trace on stack exchange here when I thought this was a config issue. I now think it's a geth bug and am raising it here.

I also ran lsof and see that geth is actually listening on 30303. However, my admin.nodeInfo shows below.

mynode@mynode:~$ sudo lsof -i UDP:30303
COMMAND  PID          USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
geth    5494 mynode *588u  IPv6  95419      0t0  UDP *:30303 
  ports: {
    discovery: 1038,
    listener: 30303
  },

My enode also shows discport=1038 How does this local nodeInfo get set? It now appears that this issue is geth relaying the wrong information to peers in its enr/enode.

@fjl
Copy link
Contributor

fjl commented Apr 2, 2024

There is an internal prediction process that attempts to figure out the node's own address based on statements from other nodes. We have this process in order to guess the NATed endpoint of the node. Looks like either the prediction isn't working in your case.

@Eisenhower1986
Copy link

This issue does look like a potential bug in Geth. In the situation you describe, Geth is showing the wrong discovery port in admin.nodeInfo, which may cause peers to not recognize your node correctly.

To fix this issue, first make sure you are using the latest version of Geth. Sometimes problems are fixed in older versions. Also, check Geth's logs for any error messages or warnings about discovered port changes. This may help determine the root cause of the problem.

Then when starting Geth, try to use the --discovery.port parameter to manually set the discovery port to see if you can keep the port unchanged stably.

@iw4p
Copy link

iw4p commented Apr 20, 2024

--discovery.port can help. good example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants