diff options
| author |   Alexander Chernavin <achernavin@netgate.com> | 2022-09-23 12:41:31 +0000 |
|---|---|---|
| committer |   Matthew Smith <mgsmith@netgate.com> | 2022-09-28 13:58:19 +0000 |
| commit | cf9144e65f37402fc6f7dacb7bd7bad6fd596784 (patch) | |
| tree | b62b8ee793270b8291ed1b4a0a501551494ed1be /extras/strongswan/vpp_sswan/kernel_vpp_ipsec.c | |
| parent | ce668aa3f6b79ca505d1282ee4ba2b3c26fb126c (diff) | |
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
Diffstat (limited to 'extras/strongswan/vpp_sswan/kernel_vpp_ipsec.c')
0 files changed, 0 insertions, 0 deletions