From: Ido Schimmel <idosch@nvidia.com>
To: <netdev@vger.kernel.org>
Cc: <davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
<edumazet@google.com>, <horms@kernel.org>, <paul@paul-moore.com>,
<dsahern@kernel.org>, <petrm@nvidia.com>,
<linux-security-module@vger.kernel.org>,
Ido Schimmel <idosch@nvidia.com>
Subject: [PATCH net-next v2 7/8] selftests: traceroute: Test traceroute with different source IPs
Date: Mon, 8 Sep 2025 10:32:37 +0300 [thread overview]
Message-ID: <20250908073238.119240-8-idosch@nvidia.com> (raw)
In-Reply-To: <20250908073238.119240-1-idosch@nvidia.com>
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>
---
tools/testing/selftests/net/traceroute.sh | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/traceroute.sh b/tools/testing/selftests/net/traceroute.sh
index 8dc4e5d03e43..0ab9eccf1499 100755
--- a/tools/testing/selftests/net/traceroute.sh
+++ b/tools/testing/selftests/net/traceroute.sh
@@ -196,9 +196,10 @@ run_traceroute6()
################################################################################
# traceroute test
#
-# Verify that traceroute from H1 to H2 shows 1.0.1.1 in this scenario
+# Verify that traceroute from H1 to H2 shows 1.0.3.1 and 1.0.1.1 when
+# traceroute uses 1.0.3.3 and 1.0.1.3 as the source IP, respectively.
#
-# 1.0.3.1/24
+# 1.0.3.3/24 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 ----
@@ -226,6 +227,7 @@ setup_traceroute()
connect_ns $h1 eth0 1.0.1.3/24 - \
$router eth1 1.0.3.1/24 -
+ ip -n "$h1" addr add 1.0.3.3/24 dev eth0
ip netns exec $h1 ip route add default via 1.0.1.1
ip netns exec $router ip addr add 1.0.1.1/24 dev eth1
@@ -248,9 +250,12 @@ run_traceroute()
RET=0
- # traceroute host-2 from host-1 (expects 1.0.1.1). Takes a while.
- run_cmd $h1 "traceroute 1.0.2.4 | grep -q 1.0.1.1"
+ # traceroute host-2 from host-1. Expect a source IP that is on the same
+ # subnet as destination IP of the ICMP error message.
+ run_cmd "$h1" "traceroute -s 1.0.1.3 1.0.2.4 | grep -q 1.0.1.1"
check_err $? "traceroute did not return 1.0.1.1"
+ run_cmd "$h1" "traceroute -s 1.0.3.3 1.0.2.4 | grep -q 1.0.3.1"
+ check_err $? "traceroute did not return 1.0.3.1"
log_test "IPv4 traceroute"
cleanup_traceroute
--
2.51.0
next prev parent reply other threads:[~2025-09-08 7:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 7:32 [PATCH net-next v2 0/8] ipv4: icmp: Fix source IP derivation in presence of VRFs Ido Schimmel
2025-09-08 7:32 ` [PATCH net-next v2 1/8] ipv4: cipso: Simplify IP options handling in cipso_v4_error() Ido Schimmel
2025-09-08 7:51 ` Eric Dumazet
2025-09-08 7:32 ` [PATCH net-next v2 2/8] ipv4: icmp: Pass IPv4 control block structure as an argument to __icmp_send() Ido Schimmel
2025-09-08 7:55 ` Eric Dumazet
2025-09-08 7:32 ` [PATCH net-next v2 3/8] ipv4: icmp: Fix source IP derivation in presence of VRFs Ido Schimmel
2025-09-08 7:32 ` [PATCH net-next v2 4/8] selftests: traceroute: Return correct value on failure Ido Schimmel
2025-09-08 7:32 ` [PATCH net-next v2 5/8] selftests: traceroute: Use require_command() Ido Schimmel
2025-09-08 7:32 ` [PATCH net-next v2 6/8] selftests: traceroute: Reword comment Ido Schimmel
2025-09-08 7:32 ` Ido Schimmel [this message]
2025-09-08 7:32 ` [PATCH net-next v2 8/8] selftests: traceroute: Add VRF tests Ido Schimmel
2025-09-11 10:40 ` [PATCH net-next v2 0/8] ipv4: icmp: Fix source IP derivation in presence of VRFs patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250908073238.119240-8-idosch@nvidia.com \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@paul-moore.com \
--cc=petrm@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox