tree b62b8ee793270b8291ed1b4a0a501551494ed1be
parent ce668aa3f6b79ca505d1282ee4ba2b3c26fb126c
author Alexander Chernavin <achernavin@netgate.com> 1663936891 +0000
committer Matthew Smith <mgsmith@netgate.com> 1664373499 +0000

tests: stabilize wireguard ratelimiting test

Type: test

"test_wg_handshake_ratelimiting_multi_peer" has been unstable recently
because the test strongly relies on execution speed. Currently, the test
triggers ratelimiting for peer 1 and sends handshake initiations from
peer 1 and 2 mixed up. After that, the test expects that all handshake
initiations for peer 1 are ratelimited and a handshake response for peer
2 is received.

Ratelimiting is based on the token bucket algorithm. The more time
passes between triggering ratelimiting for peer 1 and sending a mixture
of handshake initiations from peer 1 and 2, the more tokens will be
added into the bucket for peer 1. Depending on delays between these
steps, the number of tokens might be enough to process handshake
initiations from peer 1 while they are expected to be rejected due to
ratelimiting.

With this change, these two steps are combined into one and the logic
modified. The test triggers ratelimiting for both peer 1 and 2. Packets
that trigger ratelimiting and that are to be rejected are sent in one
batch that is going to reduce delays between packet processing. Also,
verify that number of rejected handshake messages is in expected range
instead of verifying the exact number as it still may slightly vary.

Also, this should finish making the wireguard tests stable on Ubuntu
22.04 and Debian 11.

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