lightningd: don't disconnect when sending error for unknown channel_reestablish - #9404
Closed
vincenzopalazzo wants to merge 2 commits into
Closed
Conversation
…eestablish When a peer sends WIRE_CHANNEL_REESTABLISH for a channel we don't know about (e.g. dual-funding, where we deleted the unsaved channel on disconnect but the peer saved it in DUALOPEND_OPEN_COMMIT_READY), we sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2 tasks
Collaborator
Author
|
Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1
errorsemantics in the PR) still applies and is being addressed.Summary
WIRE_CHANNEL_REESTABLISHfor an unknown channel, send the error without disconnectingDUALOPEND_OPEN_COMMIT_READYthat retries indefinitelyThe bug: during dual-funding, if one side saves the channel (reaches
DUALOPEND_OPEN_COMMIT_READY) but the other deletes its unsaved copy on disconnect, reconnects create an infinite loop. The saved side sendsCHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer'sdualopenddoesn't receive the error before the socket closes,dualopen_errmsgis called withdisconnect=false, which callschannel_fail_transientinstead of deleting the channel, and the cycle repeats.By not disconnecting, the error reliably reaches the peer's
dualopend, which processes it viapeer_failed_received_errmsg(disconnect=true)and properly deletes the stale channel.Test plan
make check-unitspasses (done locally)test_disconnect_openerFixes #8822