tree 2b9159990ff7f5d96bf507bb0e74dbe3f663cbda
parent ab15770ec63367498dd277c83a577a52594953e8
author Alexander Chernavin <achernavin@netgate.com> 1664205087 +0000
committer Alexander Chernavin <achernavin@netgate.com> 1664275832 +0000

wireguard: fix re-handshake timer when response sent

Type: fix

As per the protocol:

  A handshake initiation is retried after "REKEY_TIMEOUT + jitter" ms,
  if a response has not been received...

Currently, if retransmit handshake timer is started, it will trigger
after "REKEY_TIMEOUT + jitter" ms and will try to send a handshake
initiation via wg_send_handshake() given that no responses have been
received. wg_send_handshake() will verify that time stored in
REKEY_TIMEOUT has passed since last handshake initiation sending and if
has, will send a handshake initiation. Time when a handshake initiation
was last sent is stored in last_sent_handshake.

The problem is that last_sent_handshake is not only updated in
wg_send_handshake() when sending handshake initiations but also in
wg_send_handshake_response() when sending handshake responses. When
retransmit handshake timer triggers and a handshake response has been
sent recently, a handshake initiation will not be sent because for
wg_send_handshake() it will look like that time stored in REKEY_TIMEOUT
has not passed yet. Also, the timer will not be restarted.

wg_send_handshake_response() must not update last_sent_handshake,
because this time is used only when sending handshake intitiations. And
the protocol does not say that handshake initiation retransmission and
handshake response sending (i.e. replying to authenticated handshake
initiations) must coordinate.

With this fix, stop updating last_sent_handshake in
wg_send_handshake_response().

Also, this fixes tests that used to wait for "REKEY_TIMEOUT + 1" seconds
and did not receive any handshake initiations. Then they fail.

Also, long-running tests that send wrong packets and do not expect
anything in reply may now receive handshake intiations, consider them as
replies to the wrond packets, and fail. Those are updated to filter out
handshake initiations in such verifications. Moreover, after sending
wrong packets, error counters are already inspected there to confirm
packet processing was unsuccessful.

Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I43c428c97ce06cb8a79d239453cb5f6d1ed609d6