summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/net/traceroute.sh
AgeCommit message (Collapse)Author
2025-10-29selftests: traceroute: Add ICMP extensions testsIdo Schimmel
Test that ICMP extensions are reported correctly when enabled and not reported when disabled. Test both IPv4 and IPv6 and using different packet sizes, to make sure trimming / padding works correctly. Disable ICMP rate limiting (defaults to 1 per-second per-target) so that the kernel will always generate ICMP errors when needed. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20251027082232.232571-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-11selftests: traceroute: Add VRF testsIdo Schimmel
Create versions of the existing test cases where the routers generating the ICMP error messages are using VRFs. Check that the source IPs of these messages do not change in the presence of VRFs. IPv6 always behaved correctly, but IPv4 fails when reverting "ipv4: icmp: Fix source IP derivation in presence of VRFs". Without IPv4 change: # ./traceroute.sh TEST: IPv6 traceroute [ OK ] TEST: IPv6 traceroute with VRF [ OK ] TEST: IPv4 traceroute [ OK ] TEST: IPv4 traceroute with VRF [FAIL] traceroute did not return 1.0.3.1 $ echo $? 1 The test fails because the ICMP error message is sent with the VRF device's IP (1.0.4.1): # traceroute -n -s 1.0.1.3 1.0.2.4 traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets 1 1.0.4.1 0.165 ms 0.110 ms 0.103 ms 2 1.0.2.4 0.098 ms 0.085 ms 0.078 ms # traceroute -n -s 1.0.3.3 1.0.2.4 traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets 1 1.0.4.1 0.201 ms 0.138 ms 0.129 ms 2 1.0.2.4 0.123 ms 0.105 ms 0.098 ms With IPv4 change: # ./traceroute.sh TEST: IPv6 traceroute [ OK ] TEST: IPv6 traceroute with VRF [ OK ] TEST: IPv4 traceroute [ OK ] TEST: IPv4 traceroute with VRF [ OK ] $ echo $? 0 Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250908073238.119240-9-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11selftests: traceroute: Test traceroute with different source IPsIdo Schimmel
When generating ICMP error messages, the kernel will prefer a source IP that is on the same subnet as the destination IP (see inet_select_addr()). Test this behavior by invoking traceroute with different source IPs and checking that the ICMP error message is generated with a source IP in the same subnet. Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250908073238.119240-8-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11selftests: traceroute: Reword commentIdo Schimmel
Both of the addresses are configured as primary addresses, but the kernel is expected to choose 10.0.1.1/24 as the source IP of the ICMP error message since it is on the same subnet as the destination IP of the message (10.0.1.3/24). Reword the comment to reflect that. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250908073238.119240-7-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11selftests: traceroute: Use require_command()Ido Schimmel
Use require_command() so that the test will return SKIP (4) when a required command is not present. Before: # ./traceroute.sh SKIP: Could not run IPV6 test without traceroute6 SKIP: Could not run IPV4 test without traceroute $ echo $? 0 After: # ./traceroute.sh TEST: traceroute6 not installed [SKIP] $ echo $? 4 Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250908073238.119240-6-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11selftests: traceroute: Return correct value on failureIdo Schimmel
The test always returns success even if some tests were modified to fail. Fix by converting the test to use the appropriate library functions instead of using its own functions. Before: # ./traceroute.sh TEST: IPV6 traceroute [FAIL] TEST: IPV4 traceroute [ OK ] Tests passed: 1 Tests failed: 1 $ echo $? 0 After: # ./traceroute.sh TEST: IPv6 traceroute [FAIL] traceroute6 did not return 2000:102::2 TEST: IPv4 traceroute [ OK ] $ echo $? 1 Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250908073238.119240-5-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert traceroute.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./traceroute.sh TEST: IPV6 traceroute [ OK ] TEST: IPV4 traceroute [ OK ] Tests passed: 2 Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2019-11-06selftest: net: add some traceroute testsFrancesco Ruggeri
Added the following traceroute tests. IPV6: Verify that in this scenario ------------------------ N2 | | ------ ------ N3 ---- | R1 | | R2 |------|H2| ------ ------ ---- | | ------------------------ N1 | ---- |H1| ---- where H1's default route goes through R1 and R1's default route goes through R2 over N2, traceroute6 from H1 to H2 reports R2's address on N2 and not N1. IPV4: Verify that traceroute from H1 to H2 shows 1.0.1.1 in this scenario 1.0.3.1/24 ---- 1.0.1.3/24 1.0.1.1/24 ---- 1.0.2.1/24 1.0.2.4/24 ---- |H1|--------------------------|R1|--------------------------|H2| ---- N1 ---- N2 ---- where net.ipv4.icmp_errors_use_inbound_ifaddr is set on R1 and 1.0.3.1/24 and 1.0.1.1/24 are respectively R1's primary and secondary address on N1. v2: fixed some typos, and have bridge in R1 instead of R2 in IPV6 test. Signed-off-by: Francesco Ruggeri <fruggeri@arista.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>