lightninglabs / lightninglabs/lightning-node-connect
Unable to reconnect to node via LNC when network connection was down (e. g. airplane mode was on)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 85
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Description
I found this one while using Zeus, described it also there (https://github.com/ZeusLN/zeus/issues/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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the LncModule connectServer() and isConnected() paths involved after the network returns, using the Zeus reproduction steps to observe the failed reconnect. Done means an LNC connection can recover after a network interruption and after restarting the app, without the reported proxy or payload errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100