@@ -4,6 +4,7 @@
#include <errno.h>
#include <fcntl.h>
+#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
@@ -985,4 +986,12 @@ XFAIL_ADD(tun_vnet_udptnl, 6in4_over_maxbytes, recv_gso_packet);
XFAIL_ADD(tun_vnet_udptnl, 4in6_over_maxbytes, recv_gso_packet);
XFAIL_ADD(tun_vnet_udptnl, 6in6_over_maxbytes, recv_gso_packet);
-TEST_HARNESS_MAIN
+int main(int argc, char **argv)
+{
+ if (unshare(CLONE_NEWNET) < 0) {
+ perror("unshare(CLONE_NEWNET)");
+ return 1;
+ }
+
+ return test_harness_run(argc, argv);
+}
BugLink: https://bugs.launchpad.net/bugs/2158217 The tun_vnet_udptnl fixture creates geneve tunnels that bind a UDP encap socket on port 4789. When the test runs in the default network namespace, other network activity (VPN tunnels, container networking, libvirt bridges, etc.) can interfere with the geneve decapsulation path, causing send_gso_packet variants to sporadically fail with zero bytes received: tun.c:947:send_gso_packet:Expected ret (0) == variant->data_size (1423) tun.c:948:send_gso_packet:Expected r_num_mss (0) == variant->r_num_mss (2) The failure pattern is non-deterministic: different variants fail on each run, all tunnel types (4in4, 4in6, 6in4, 6in6) are affected, and only the decap direction (TUN fd -> geneve -> socket) is impacted while the encap direction (socket -> geneve -> TUN fd) always succeeds. Fix by calling unshare(CLONE_NEWNET) at program startup so all TUN and geneve devices are created in a pristine, isolated namespace with no competing traffic. This follows the same pattern already used by several other net selftests (so_incoming_cpu, tcp_port_share, icmp_rfc4884, ipv6_fragmentation, so_netns_cookie, ipsec, tcp_ao). Fixes: 24e59f26eef2 ("selftest: tun: Add helpers for GSO over UDP tunnel") Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com> --- tools/testing/selftests/net/tun.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)