Unable to reconnect to node via LNC when network connection was down (e. g. airplane mode was on)

[myxmaster]

I found this one while using Zeus, described it also there (ZeusLN/zeus#1483), but it probably needs to be fixed on LNC side.

Problem

When connected to a node via LNC and the connection breaks during app usage, it cannot be recovered (when you bring network connection down/up while Zeus runs in background, LNC connection is not permanently broken - no idea what this is about...). Not even when restarting the app.

I already tried to debug this and found, that the connectServer() method of the LncModule does not return an error, but the isConnected() method returns false every time.

Reproduce (using Zeus)

• Connect to node via LNC (Lightning Node Connect)
• Bring network connection down, e. g. by enabling airplane mode
• Bring network connection up again
• Refresh balance
  -> Error is shown after some time:

Error: rpc error: code = Unavailable desc = error reading from server: error decrypting payload: error receiving from go-back-n connection: cannot receive, gbn exited

• Click restart button

->Error is shown:

Failed to connect the LNC client to the proxy server

[positiveblue]

I think I have experienced this myself.

When you say LNC connection is not permanently broken - no idea what this is about...). Not even when restarting the app., what do you mean? Stopping the app and starting it again does not solve the problem?

[myxmaster]

When network connection is brought down/up while Zeus runs in background, next Zeus app start does have issues (crash or endless loading), but after restarting the app, it works again. That is not the case when network connection is brought down/up during app usage - this will kill LNC connection and it can't recover (until a timeout which I don't know how long it takes).

[joergrs]

I am facing the same issue from time to time. My LND with LightingTerminal-LNC is running on a machine in my LAN.

To reproduce the problem I have to do the following steps

1. With the phone in my local Wifi, open up Zeus -> connection OK
2. Kill Zeus and wait for a minute
3. Turn off Wifi -> phones switches to mobile data
4. Open Zeus -> "Failed to connect the LNC client to the proxy server"

Once it is in this state, I have to wait for some time (10 to 30 minutes?) until I can use Zeus again. No matter if I'm on WiFi or mobile data.

If it helps, I could try to make a screencast of the process.

A fix would be really awesome 😎
As if this would happen while just having purchased something in a store that accepts Lightning, it would really kill the mood 😉

Thanks!

[LOCHER-21]

Got the same problem on Zeus but I think this is a Zeus related problem. This behavior is not LNC exclusive. Got this problem on Zeus with LNC and REST.

[myxmaster]

I just tested and I can definitely not confirm this for REST connections with Zeus. There is no issue at all after connection is back up.

With LNC though, I can still recreate some connection problems after the connection is back up (channels and activity e.g. not loading for some time), but it is not permanent anymore, it recovers now. Even without killing/restarting Zeus...

So, maybe we can close this? Not sure, since it is still not perfect.

[myxmaster]

I am wondering though, what happens when the LNC connection is not closed properly? I fixed an issue over at @ZeusLN where I noticed that if we are not closing the connection and then trying to reconnect, we have exactly those problems where we see the Failed to connect the LNC client to the proxy server error and can't connect for quite a long time (not a normal timeout, it's like hours).

Anyway, so I am wondering about that required "connection closing" in context of any scenarios: Going into airplane mode, phone battery died, whatever. How can we prevent problems when we want to connect again any time soon?

[ellemouton]

Thanks for the extra detail @myxmaster 🙏

Yeah I think there are some stability improvements that can be implemented still. Perhaps we should "timeout & await handshake" sooner than we currently do.

We will definitely assess & continue to work on stability.