From: Wilmer Paulino Date: Fri, 12 Apr 2024 17:23:45 +0000 (-0700) Subject: Fix race between handshake_complete and timer_tick_occurred X-Git-Tag: v0.0.123-beta~9^2 X-Git-Url: http://git.bitcoin.ninja/?a=commitdiff_plain;h=b835e4f67af1689ab541c1b3ea26cc3a5b643374;p=rust-lightning Fix race between handshake_complete and timer_tick_occurred The initial noise handshake on connection establishment must complete within a single timer tick. This timeout is enforced via `awaiting_pong_timer_tick_intervals` whenever a timer tick fires while our handshake has yet to complete. Currently, on an inbound connection, if a timer tick fires after we've sent act two of the noise handshake along with our init message and before receiving the counterparty's init message, we begin enforcing such timeout. Even if we immediately continue to process the counterparty's init message to complete to handshake, the timeout enforcement is not cleared. With the handshake complete, `awaiting_pong_timer_tick_intervals` is now tracked to enforce a pong timeout, except a ping was never actually sent. If a single timer tick fires again without having received a message from the peer, or enough timer ticks fire to trigger the `MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER` logic, we'll end up disconnecting the peer due to a timeout for a pong we'll never receive. We fix this by always resetting `awaiting_pong_timer_tick_intervals` upon processing our counterparty's init message. --- diff --git a/lightning/src/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs index 9c27a2346..da96693f0 100644 --- a/lightning/src/ln/peer_handler.rs +++ b/lightning/src/ln/peer_handler.rs @@ -1475,7 +1475,6 @@ impl { let their_node_id = try_potential_handleerror!(peer, @@ -1488,7 +1487,6 @@ impl { if peer.pending_read_is_header { @@ -1681,6 +1679,7 @@ impl