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

Wrong port is gossiped, in addition to correct one #5305

Closed
laanwj opened this issue Jun 6, 2022 · 8 comments
Closed

Wrong port is gossiped, in addition to correct one #5305

laanwj opened this issue Jun 6, 2022 · 8 comments
Assignees
Milestone

Comments

@laanwj
Copy link
Contributor

laanwj commented Jun 6, 2022

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:

% lcli listnodes [M]
{
   "nodes": [
      {
         "nodeid": "[M]",
…
         "addresses": [
            {
               "type": "ipv4",
               "address": "[A]",
               "port": 9735
            },
            {
               "type": "ipv4",
               "address": "[A]",
               "port": 9736
            },
            {
               "type": "ipv6",
               "address": "[B]",
               "port": 9736
            },
            {
               "type": "torv3",
               "address": "[C].onion",
               "port": 9736
            }
         ]
      }
   ]
}

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:

    --proxy 127.0.0.1:9050 \
    --addr '0.0.0.0:9736' \
    --addr '[::]:9736' \
    --announce-addr '[C].onion:9736' \

getinfo output shows, correctly:

{
   "id": "[M]",
…
   "address": [
      {
         "type": "ipv4",
         "address": "[A]",
         "port": 9736
      },
      {
         "type": "ipv6",
         "address": "[B]",
         "port": 9736
      },
      {
         "type": "torv3",
         "address": "[C].onion",
         "port": 9736
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "0.0.0.0",
         "port": 9736
      },
      {
         "type": "ipv6",
         "address": "::",
         "port": 9736
      }
   ],
   "version": "v0.11.0.1-36-g74ddc15",
…
}
@laanwj
Copy link
Contributor Author

laanwj commented Jun 7, 2022

amboss.space has a history for the node that shows 9735 appearing and disappearing, it's really strange:

amboss

None of these are intentional configuration changes.

Edit: looks like they correlate roughly with server restarts:

2022-03-31T15:19:33.974Z INFO    lightningd: Server started with public key —
2022-04-07T17:54:35.409Z INFO    lightningd: Server started with public key —
2022-04-08T16:07:24.407Z INFO    lightningd: Server started with public key —
2022-05-02T18:02:38.327Z INFO    lightningd: Server started with public key —
2022-06-03T14:52:29.719Z INFO    lightningd: Server started with public key —

(it's only a subset though, there were more restarts in this time period)

Edit.2: Just found this option:

--autolisten <arg>                      If true, listen on default port and
                                        announce if it seems to be a public
                                        interface (default: true)

Will try setting it to false, as it seems what is happening here except for the actual binding.

@kroese
Copy link

kroese commented Jun 8, 2022

Maybe you can also try if setting disable-ip-discovery makes any difference. Because it only is able to discover the IP and not the port, so if will automaticly append 9735.

@vincenzopalazzo
Copy link
Contributor

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

@laanwj
Copy link
Contributor Author

laanwj commented Jun 20, 2022

Thanks @kroese and @vincenzopalazzo .

It doesn't look like -autolisten false solved the issue. Will try with disable-ip-discovery. I'll have to pass in all addresses with --announce-addr in that case, I suppose. This is okay, they're all static.

Edit: uhm, I now announce the IPv4 and IPv6 addresses twice, scrap that.

@kroese
Copy link

kroese commented Jun 20, 2022

The manual for disable-ip-discovery says:

Turn off public IP discovery to send node_announcement updates that contain the discovered IP with TCP port 9735 as announced address.

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.

@rustyrussell rustyrussell added this to the v0.12 milestone Jun 21, 2022
@rustyrussell
Copy link
Contributor

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!

@m-schmoock
Copy link
Collaborator

m-schmoock commented Jun 21, 2022

Yes. I'll open up an PR.
Maybe disable discovery at all when something is announced manually.

@m-schmoock
Copy link
Collaborator

Or maybe only do discovery on IP protocols that are not configured manually.

m-schmoock added a commit to m-schmoock/lightning that referenced this issue Jun 27, 2022
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
m-schmoock added a commit to m-schmoock/lightning that referenced this issue Jul 11, 2022
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
niftynei pushed a commit that referenced this issue Jul 12, 2022
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
whitslack pushed a commit to whitslack/lightning that referenced this issue Aug 30, 2022
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
whitslack pushed a commit to whitslack/lightning that referenced this issue Aug 30, 2022
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
whitslack pushed a commit to whitslack/lightning that referenced this issue Oct 8, 2022
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
whitslack pushed a commit to whitslack/lightning that referenced this issue Oct 28, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants