tests: stabilize wireguard ratelimiting test 47/37247/6
authorAlexander Chernavin <achernavin@netgate.com>
Fri, 23 Sep 2022 12:41:31 +0000 (12:41 +0000)
committerMatthew Smith <mgsmith@netgate.com>
Wed, 28 Sep 2022 13:58:19 +0000 (13:58 +0000)
commitcf9144e65f37402fc6f7dacb7bd7bad6fd596784
treeb62b8ee793270b8291ed1b4a0a501551494ed1be
parentce668aa3f6b79ca505d1282ee4ba2b3c26fb126c
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
test/test_wireguard.py