| Message ID | 20241130113314.6488-2-ansuelsmth@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [net,1/2] selftests: net: lib: fix broken ping with coreutils ping util | expand |
On Sat, Nov 30, 2024 at 12:33:10PM +0100, Christian Marangi wrote: > It seems real hardware requires some time to stabilize and actually > works after an 'ip link up'. This is not the case for veth as everything > is simulated but this is a requirement for real hardware to permit > receiving packet. > > Without this the very fist test for unicast always fails on real > hardware. With the introduced sleep of one second after mc_route_prepare, > the test corretly pass as the packet can correctly be delivered. I think the analysis is not very convincing for the following reason. To wait after "ip link up", setup_wait() calls setup_wait_dev_with_timeout() which waits until "ip link show dev $dev up" reports 'state UP'. This comes from IFLA_OPERSTATE, set by linkwatch. I remember having this conversation with Danielle Ratson a few years ago: https://lore.kernel.org/netdev/20210624151515.794224-1-danieller@nvidia.com/ but the bottom line should be that, since commit facd15dfd691 ("net: core: synchronize link-watch when carrier is queried") AFAIU, an operstate of UP really means that the net device is ready of passing traffic. Failure to do so should be a device-side problem. Then I thought that maybe tcpdump needs some time to set up its filters on the receving net device. But tcpdump_start() already has "sleep 1" in it. I admit, that was purely empirical and there's no guarantee that tcpdump has finished setting up even after 1 second. If you increase it to 2, does it also solve your problem? Or do you really have to place the sleep call after the mc_route_prepare() calls, and any earlier won't help? In that case, it isolates the sleeping requirement to the multicast routes themselves?
diff --git a/tools/testing/selftests/net/forwarding/local_termination.sh b/tools/testing/selftests/net/forwarding/local_termination.sh index c35548767756..8923c741ce4b 100755 --- a/tools/testing/selftests/net/forwarding/local_termination.sh +++ b/tools/testing/selftests/net/forwarding/local_termination.sh @@ -182,6 +182,8 @@ run_test() mc_route_prepare $send_if_name mc_route_prepare $rcv_if_name + sleep 1 + send_uc_ipv4 $send_if_name $rcv_dmac send_uc_ipv4 $send_if_name $MACVLAN_ADDR send_uc_ipv4 $send_if_name $UNKNOWN_UC_ADDR1
It seems real hardware requires some time to stabilize and actually works after an 'ip link up'. This is not the case for veth as everything is simulated but this is a requirement for real hardware to permit receiving packet. Without this the very fist test for unicast always fails on real hardware. With the introduced sleep of one second after mc_route_prepare, the test corretly pass as the packet can correctly be delivered. Cc: stable@vger.kernel.org Fixes: 90b9566aa5cd ("selftests: forwarding: add a test for local_termination.sh") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- tools/testing/selftests/net/forwarding/local_termination.sh | 2 ++ 1 file changed, 2 insertions(+)