-
Notifications
You must be signed in to change notification settings - Fork 913
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
Wrong port is gossiped, in addition to correct one #5305
Comments
amboss.space has a history for the node that shows 9735 appearing and disappearing, it's really strange: None of these are intentional configuration changes. Edit: looks like they correlate roughly with server restarts:
(it's only a subset though, there were more restarts in this time period) Edit.2: Just found this option:
Will try setting it to |
Maybe you can also try if setting |
Mh! I did not debug it, and I put here only a pointer that we had changed somethings in the default port but there was some refusal that this PR will remove #5242 Maybe can help |
Thanks @kroese and @vincenzopalazzo . It doesn't look like Edit: uhm, I now announce the IPv4 and IPv6 addresses twice, scrap that. |
The manual for disable-ip-discovery says:
So it seems it just adds port 9735 to the external IP without checking if that is really the port you are listening on. It would be better if it used that port instead. |
Hmm, @m-schmoock ? This shouldn't happen; we can't really tell what port is exposed, so we guess. But obviously we should not add anything if that IP is already advertized! |
Yes. I'll open up an PR. |
Or maybe only do discovery on IP protocols that are not configured manually. |
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: #5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
This will only add the discovered `remote_addr` IPs if no other addresses would be announced. Meaning whenever a public address was found by autobind or an address was specified via commandline or config, IP discovery will be disabled. Addresses: ElementsProject#5305 Note from the author: We could/should also enable IP discovery when we only have a TOR address (but without --always-use-proxy ofc). This will give nodes an option to have a bootstrap way to be reached until IP discovery can do the job in a more stable way. Changelog-Changed: Only use IP discovery as fallback when no addresses would be announced
I'm having an issue where the gossiped port is wrong, possibly part of the time. It's supposed to be 9736, but 9735 ends up in the list too:
I not only see this in my own
listnodes
, other nodes and services do, as well. I do not have anything running on port 9735, FWIW, there's only one lightningd on this system. I've only ever seen it happen for IPv4.Relevant configuration is:
getinfo
output shows, correctly:The text was updated successfully, but these errors were encountered: