mirror of
https://github.com/ElementsProject/lightning.git
synced 2025-02-22 14:42:40 +01:00
1c495ca5a8
We had multiple reports of channels being unilaterally closed because it seemed like the peer was sending old revocation numbers. Turns out, it was actually old reestablish messages! When we have a reconnection, we would put the new connection aside, and tell lightningd to close the current connection: when it did, we would restart processing of the initial reconnection. However, we could end up with *multiple* "reconnecting" connections, while waiting for an existing connection to close. Though the connections were long gone, there could still be messages queued (particularly the channel_reestablish message, which comes early on). Eventually, a normal reconnection would cause us to process one of these reconnecting connections, and channeld would see the (perhaps very old!) messages, and get confused. (I have a test which triggers this, but it also hangs the connect command, due to other issues we will fix in the next release...) Fixes: #5240 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> |
||
|---|---|---|
| .. | ||
| test | ||
| connectd.c | ||
| connectd.h | ||
| connectd_gossipd_wire.csv | ||
| connectd_wire.csv | ||
| handshake.c | ||
| handshake.h | ||
| Makefile | ||
| multiplex.c | ||
| multiplex.h | ||
| netaddress.c | ||
| netaddress.h | ||
| onion_message.c | ||
| onion_message.h | ||
| peer_exchange_initmsg.c | ||
| peer_exchange_initmsg.h | ||
| sha1.c | ||
| sha1.h | ||
| tor.c | ||
| tor.h | ||
| tor_autoservice.c | ||
| tor_autoservice.h | ||
| websocketd.c | ||