Fix race between handshake_complete and timer_tick_occurred
authorWilmer Paulino <wilmer@wilmerpaulino.com>
Fri, 12 Apr 2024 17:23:45 +0000 (10:23 -0700)
committerWilmer Paulino <wilmer@wilmerpaulino.com>
Fri, 12 Apr 2024 17:57:34 +0000 (10:57 -0700)
commitb835e4f67af1689ab541c1b3ea26cc3a5b643374
tree304c389f74ed12b908084e827848678786dac5fe
parent1d2a27d11963d0d37606458169b9e59e5165f2a9
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.
lightning/src/ln/peer_handler.rs