Peers are unable to reconnect and stuck in a deadlock after IP address change

[viaj3ro]

As described by @t-bast in https://gitter.im/ACINQ/eclair LND and eclair (possibly c-lightning) peers are unable to reconnect after a IP address change due to not trusting node_announcement:

if you change your IP address, your peers won't reconnect to you. They'll wait for you to connect to them and then will store your new IP address for future reconnections (ie they don't trust the new IP address from node_announcement alone)

This leads to a situation where even some clearnet peers have to be manually reconnected which can be quite time consuming and TOR peers are stuck in a deadlock that can only manually be resolved by the node operator of each and every TOR peer. They would have to look up the new IP address of their offline peer on one of the lightning explorer websites and manually feed it to their node. This is unlikely to happen quickly, if at all.

I changed the IP of my node more than 2 days ago and still have 65 disconnected TOR peers. Most, if not all of them seem to be running LND.

I'd suggest to use the IP from node_announcement if a connection to the last known IP fails. Can still be alternated with last known IP until success.

Also reported to eclair: ACINQ/eclair#1842

[Roasbeef]

Seems all we need to do here, is refresh the target peer IP/addr from the node announcement: https://github.com/lightningnetwork/lnd/blob/master/server.go#L3564

[ellemouton]

Is it necessary to only refresh peer advertised addresses here if the peer is an inbound peer? Why not for all peers?

Also, is an itest a good idea for something like this?

[Roasbeef]

Is it necessary to only refresh peer advertised addresses here if the peer is an inbound peer? Why not for all peers?

We do it for inbound peers there as since it's an inbound connection, we may not have the proper port they're actually listening on to connect to (we see the random port assigned by the kernel).

Also, is an itest a good idea for something like this?

I think so, to ensure that things are working as expected end to end.

A sample test would look something like:

• connect to a peer inbound
• disconnect
• restart inbound node and change the listening port
• initial peer should eventually reconnect