summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/net/tcp_ao/rst.c
AgeCommit message (Collapse)Author
2025-03-25selftests/net: Drop timeout argument from test_client_verify()Dmitry Safonov
It's always TEST_TIMEOUT_SEC, with an unjustified exception in rst test, that is more paranoia-long timeout rather than based on requirements. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20250319-tcp-ao-selftests-polling-v2-7-da48040153d1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-25selftests/net: Delete timeout from test_connect_socket()Dmitry Safonov
Unused: it's always either the default timeout or asynchronous connect(). Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20250319-tcp-ao-selftests-polling-v2-6-da48040153d1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-25selftests/net: Fetch and check TCP-MD5 countersDmitry Safonov
There are related TCP-MD5 <=> TCP and TCP-MD5 <=> TCP-AO tests that can benefit from checking the related counters, not only from validating operations timeouts. It also prepares the code for introduction of mixed select()+poll mode, see the follow-up patches. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20250319-tcp-ao-selftests-polling-v2-3-da48040153d1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-25selftests/net: Provide tcp-ao counters comparison helperDmitry Safonov
Rename __test_tcp_ao_counters_cmp() into test_assert_counters_ao() and test_tcp_ao_key_counters_cmp() into test_assert_counters_key() as they are asserts, rather than just compare functions. Provide test_cmp_counters() helper, that's going to be used to compare ao_info and netns counters as a stop condition for polling the sockets. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20250319-tcp-ao-selftests-polling-v2-2-da48040153d1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-27selftests/net: Add trace events matching to tcp_aoDmitry Safonov
Setup trace points, add a new ftrace instance in order to not interfere with the rest of the system, filtering by net namespace cookies. Raise a new background thread that parses trace_pipe, matches them with the list of expected events. Wiring up trace events to selftests provides another insight if there is anything unexpected happining in the tcp-ao code (i.e. key rotation when it's not expected). Note: in real programs libtraceevent should be used instead of this manual labor of setting ftrace up and parsing. I'm not using it here as I don't want to have an .so library dependency that one would have to bring into VM or DUT (Device Under Test). Please, don't copy it over into any real world programs, that aren't tests. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20240823-tcp-ao-selftests-upd-6-12-v4-8-05623636fe8c@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-16selftests/tcp_ao: Make RST tests less flakyDmitry Safonov
Currently, "active reset" cases are flaky, because select() is called for 3 sockets, while only 2 are expected to receive RST. The idea of the third socket was to get into request_sock_queue, but the test mistakenly attempted to connect() after the listener socket was shut down. Repair this test, it's important to check the different kernel code-paths for signing RST TCP-AO segments. Fixes: c6df7b2361d7 ("selftests/net: Add TCP-AO RST test") Reported-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-31selftests/net: Repair RST passive reset selftestDmitry Safonov
Currently, the test is racy and seems to not pass anymore. In order to rectify it, aim on TCP_TW_RST. Doesn't seem way too good with this sleep() part, but it seems as a reasonable compromise for the test. There is a plan in-line comment on how-to improve it, going to do it on the top, at this moment I want it to run on netdev/patchwork selftests dashboard. It also slightly changes tcp_ao-lib in order to get SO_ERROR propagated to test_client_verify() return value. Fixes: c6df7b2361d7 ("selftests/net: Add TCP-AO RST test") Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20240130-tcp-ao-test-key-mgmt-v2-3-d190430a6c60@arista.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-17selftests/net: Add TCP-AO RST testDmitry Safonov
Check that both active and passive reset works and correctly sign segments with TCP-AO or don't send RSTs if not possible to sign. A listening socket with backlog = 0 gets one connection in accept queue, another in syn queue. Once the server/listener socket is forcibly closed, client sockets aren't connected to anything. In regular situation they would receive RST on any segment, but with TCP-AO as there's no listener, no AO-key and unknown ISNs, no RST should be sent. And "passive" reset, where RST is sent on reply for some segment (tcp_v{4,6}_send_reset()) - there use TCP_REPAIR to corrupt SEQ numbers, which later results in TCP-AO signed RST, which will be verified and client socket will get EPIPE. No TCPAORequired/TCPAOBad segments are expected during these tests. Sample of the output: > # ./rst_ipv4 > 1..15 > # 1462[lib/setup.c:254] rand seed 1686611171 > TAP version 13 > ok 1 servered 1000 bytes > ok 2 Verified established tcp connection > ok 3 sk[0] = 7, connection was reset > ok 4 sk[1] = 8, connection was reset > ok 5 sk[2] = 9 > ok 6 MKT counters are good on server > ok 7 Verified established tcp connection > ok 8 client connection broken post-seq-adjust > ok 9 client connection was reset > ok 10 No segments without AO sign (server) > ok 11 Signed AO segments (server): 0 => 30 > ok 12 No segments with bad AO sign (server) > ok 13 No segments without AO sign (client) > ok 14 Signed AO segments (client): 0 => 30 > ok 15 No segments with bad AO sign (client) > # Totals: pass:15 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Dmitry Safonov <dima@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>