[PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[Justin Iurman]

Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new
"tunsrc" feature.

Cc: Shuah Khan <shuah@kernel.org>
Cc: linux-kselftest@vger.kernel.org
Signed-off-by: Justin Iurman <justin.iurman@6wind.com>
---
 .../net/srv6_hencap_red_l3vpn_test.sh         | 65 ++++++++++++++-----
 1 file changed, 50 insertions(+), 15 deletions(-)

diff --git a/tools/testing/selftests/net/srv6_hencap_red_l3vpn_test.sh b/tools/testing/selftests/net/srv6_hencap_red_l3vpn_test.sh
index 6a68c7eff1dc..bdc485640f79 100755
--- a/tools/testing/selftests/net/srv6_hencap_red_l3vpn_test.sh
+++ b/tools/testing/selftests/net/srv6_hencap_red_l3vpn_test.sh
@@ -345,6 +345,10 @@ setup_rt_networking()
 		ip -netns "${nsname}" addr \
 			add "${net_prefix}::${rt}/64" dev "${devname}" nodad
 
+		ip -netns "${nsname}" addr \
+			add "${net_prefix}::dead:${rt}/64" dev "${devname}" \
+			nodad preferred_lft 0
+
 		ip -netns "${nsname}" link set "${devname}" up
 	done
 
@@ -419,7 +423,8 @@ setup_rt_local_sids()
 #  $4 - SRv6 router configured for removing the SRv6 Policy (router connected
 #       to the destination host)
 #  $5 - encap mode (full or red)
-#  $6 - traffic type (IPv6 or IPv4)
+#  $6 - force tunsrc (true or false)
+#  $7 - traffic type (IPv6 or IPv4)
 __setup_rt_policy()
 {
 	local dst="$1"
@@ -427,11 +432,40 @@ __setup_rt_policy()
 	local end_rts="$3"
 	local dec_rt="$4"
 	local mode="$5"
-	local traffic="$6"
+	local with_tunsrc="$6"
+	local traffic="$7"
 	local nsname
 	local policy=''
+	local tunsrc=''
 	local n
 
+	if [ "$with_tunsrc" = "true" ]; then
+		local net_prefix
+		local drule
+		local nxt
+
+		[ "$end_rts" = "" ] && nxt="${dec_rt}" || nxt="${end_rts%% *}"
+
+		net_prefix="$(get_network_prefix "${encap_rt}" "${nxt}")"
+		tunsrc="tunsrc ${net_prefix}::dead:${encap_rt}"
+
+		eval nsname=\${$(get_rtname "${dec_rt}")}
+
+		drule="PREROUTING \
+		       -d ${VPN_LOCATOR_SERVICE}:${dec_rt}::${DT46_FUNC} \
+		       -j DROP"
+
+		if ! ip netns exec "${nsname}" \
+			ip6tables -t raw -C ${drule} &>/dev/null; then
+			ip netns exec "${nsname}" ip6tables -t raw -A ${drule}
+		fi
+
+		ip netns exec "${nsname}" ip6tables -t raw -I PREROUTING 1 \
+			-s "${net_prefix}::dead:${encap_rt}" \
+			-d ${VPN_LOCATOR_SERVICE}:${dec_rt}::${DT46_FUNC} \
+			-j ACCEPT
+	fi
+
 	eval nsname=\${$(get_rtname "${encap_rt}")}
 
 	for n in ${end_rts}; do
@@ -444,7 +478,7 @@ __setup_rt_policy()
 	if [ "${traffic}" -eq 6 ]; then
 		ip -netns "${nsname}" -6 route \
 			add "${IPv6_HS_NETWORK}::${dst}" vrf "${VRF_DEVNAME}" \
-			encap seg6 mode "${mode}" segs "${policy}" \
+			encap seg6 mode "${mode}" ${tunsrc} segs "${policy}" \
 			dev "${VRF_DEVNAME}"
 
 		ip -netns "${nsname}" -6 neigh \
@@ -455,7 +489,7 @@ __setup_rt_policy()
 		# received, otherwise the proxy arp does not work.
 		ip -netns "${nsname}" -4 route \
 			add "${IPv4_HS_NETWORK}.${dst}" vrf "${VRF_DEVNAME}" \
-			encap seg6 mode "${mode}" segs "${policy}" \
+			encap seg6 mode "${mode}" ${tunsrc} segs "${policy}" \
 			dev "${VRF_DEVNAME}"
 	fi
 }
@@ -463,13 +497,13 @@ __setup_rt_policy()
 # see __setup_rt_policy
 setup_rt_policy_ipv6()
 {
-	__setup_rt_policy "$1" "$2" "$3" "$4" "$5" 6
+	__setup_rt_policy "$1" "$2" "$3" "$4" "$5" "$6" 6
 }
 
 #see __setup_rt_policy
 setup_rt_policy_ipv4()
 {
-	__setup_rt_policy "$1" "$2" "$3" "$4" "$5" 4
+	__setup_rt_policy "$1" "$2" "$3" "$4" "$5" "$6" 4
 }
 
 setup_hs()
@@ -567,41 +601,41 @@ setup()
 	# the network path between hs-1 and hs-2 traverses several routers
 	# depending on the direction of traffic.
 	#
-	# Direction hs-1 -> hs-2 (H.Encaps.Red)
+	# Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
 	#  - rt-3,rt-4 (SRv6 End behaviors)
 	#  - rt-2 (SRv6 End.DT46 behavior)
 	#
 	# Direction hs-2 -> hs-1 (H.Encaps.Red)
 	#  - rt-1 (SRv6 End.DT46 behavior)
-	setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red
-	setup_rt_policy_ipv6 1 2 "" 1 encap.red
+	setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red true
+	setup_rt_policy_ipv6 1 2 "" 1 encap.red false
 
 	# create an IPv4 VPN between hosts hs-1 and hs-2
 	# the network path between hs-1 and hs-2 traverses several routers
 	# depending on the direction of traffic.
 	#
-	# Direction hs-1 -> hs-2 (H.Encaps.Red)
+	# Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
 	# - rt-2 (SRv6 End.DT46 behavior)
 	#
 	# Direction hs-2 -> hs-1 (H.Encaps.Red)
 	#  - rt-4,rt-3 (SRv6 End behaviors)
 	#  - rt-1 (SRv6 End.DT46 behavior)
-	setup_rt_policy_ipv4 2 1 "" 2 encap.red
-	setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red
+	setup_rt_policy_ipv4 2 1 "" 2 encap.red true
+	setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false
 
 	# create an IPv6 VPN between hosts hs-3 and hs-4
 	# the network path between hs-3 and hs-4 traverses several routers
 	# depending on the direction of traffic.
 	#
-	# Direction hs-3 -> hs-4 (H.Encaps.Red)
+	# Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc)
 	# - rt-2 (SRv6 End Behavior)
 	# - rt-4 (SRv6 End.DT46 behavior)
 	#
 	# Direction hs-4 -> hs-3 (H.Encaps.Red)
 	#  - rt-1 (SRv6 End behavior)
 	#  - rt-3 (SRv6 End.DT46 behavior)
-	setup_rt_policy_ipv6 4 3 "2" 4 encap.red
-	setup_rt_policy_ipv6 3 4 "1" 3 encap.red
+	setup_rt_policy_ipv6 4 3 "2" 4 encap.red true
+	setup_rt_policy_ipv6 3 4 "1" 3 encap.red false
 
 	# testing environment was set up successfully
 	SETUP_ERR=0
@@ -819,6 +853,7 @@ test_command_or_ksft_skip ip
 test_command_or_ksft_skip ping
 test_command_or_ksft_skip sysctl
 test_command_or_ksft_skip grep
+test_command_or_ksft_skip ip6tables
 
 test_iproute2_supp_or_ksft_skip
 test_vrf_or_ksft_skip
-- 
2.39.2

Re: [PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[Andrea Mayer]

On Mon, 16 Mar 2026 17:29:55 +0100
Justin Iurman <justin.iurman@6wind.com> wrote:

> Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new
> "tunsrc" feature.
> 
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: linux-kselftest@vger.kernel.org
> Signed-off-by: Justin Iurman <justin.iurman@6wind.com>
> ---
>  .../net/srv6_hencap_red_l3vpn_test.sh         | 65 ++++++++++++++-----
>  1 file changed, 50 insertions(+), 15 deletions(-)
> 

Hi Justin,
 
Thanks for working on this!
I'll focus on a couple of design aspects for now, and we can look at the
details once we settle on those.

>
> [snip]
>  
>  setup_hs()
> @@ -567,41 +601,41 @@ setup()
>  	# the network path between hs-1 and hs-2 traverses several routers
>  	# depending on the direction of traffic.
>  	#
> -	# Direction hs-1 -> hs-2 (H.Encaps.Red)
> +	# Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
>  	#  - rt-3,rt-4 (SRv6 End behaviors)
>  	#  - rt-2 (SRv6 End.DT46 behavior)
>  	#
>  	# Direction hs-2 -> hs-1 (H.Encaps.Red)
>  	#  - rt-1 (SRv6 End.DT46 behavior)
> -	setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red
> -	setup_rt_policy_ipv6 1 2 "" 1 encap.red
> +	setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red true
> +	setup_rt_policy_ipv6 1 2 "" 1 encap.red false
>  
>  	# create an IPv4 VPN between hosts hs-1 and hs-2
>  	# the network path between hs-1 and hs-2 traverses several routers
>  	# depending on the direction of traffic.
>  	#
> -	# Direction hs-1 -> hs-2 (H.Encaps.Red)
> +	# Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
>  	# - rt-2 (SRv6 End.DT46 behavior)
>  	#
>  	# Direction hs-2 -> hs-1 (H.Encaps.Red)
>  	#  - rt-4,rt-3 (SRv6 End behaviors)
>  	#  - rt-1 (SRv6 End.DT46 behavior)
> -	setup_rt_policy_ipv4 2 1 "" 2 encap.red
> -	setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red
> +	setup_rt_policy_ipv4 2 1 "" 2 encap.red true
> +	setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false
>  
>  	# create an IPv6 VPN between hosts hs-3 and hs-4
>  	# the network path between hs-3 and hs-4 traverses several routers
>  	# depending on the direction of traffic.
>  	#
> -	# Direction hs-3 -> hs-4 (H.Encaps.Red)
> +	# Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc)
>  	# - rt-2 (SRv6 End Behavior)
>  	# - rt-4 (SRv6 End.DT46 behavior)
>  	#
>  	# Direction hs-4 -> hs-3 (H.Encaps.Red)
>  	#  - rt-1 (SRv6 End behavior)
>  	#  - rt-3 (SRv6 End.DT46 behavior)
> -	setup_rt_policy_ipv6 4 3 "2" 4 encap.red
> -	setup_rt_policy_ipv6 3 4 "1" 3 encap.red
> +	setup_rt_policy_ipv6 4 3 "2" 4 encap.red true
> +	setup_rt_policy_ipv6 3 4 "1" 3 encap.red false
>  
>  	# testing environment was set up successfully
>  	SETUP_ERR=0


The paths marked "true" here were testing the encap.red baseline before
this change. They need to stay exactly as they were originally.
Furthermore, if tunsrc is not supported by the kernel running the test,
the ip route command with tunsrc will fail during setup() (since
set -e is used), and the entire script dies before any test runs.
 
The idea here is to avoid duplicating the entire test suite, while still
providing dedicated test cases for the new per-route tunsrc. A reasonable
approach could be adding the tunsrc checks as new, separate test cases
that run after the baseline ones, leaving the existing paths completely
untouched.
 
For example, a dedicated test_tunsrc() function could take care of the
whole thing for a given path: setting up the tunsrc address, installing
the route with tunsrc, verifying the behavior, cleaning up, and finally
restoring the original route.

>
> [snip]
> @@ -819,6 +853,7 @@ test_command_or_ksft_skip ip
>  test_command_or_ksft_skip ping
>  test_command_or_ksft_skip sysctl
>  test_command_or_ksft_skip grep
> +test_command_or_ksft_skip ip6tables
>

This will skip the entire script if ip6tables is not present, which
takes down the baseline tests too.
I think a probe at startup that checks for both tunsrc support and
ip6tables would work well here. If either is missing, we can
just gracefully skip the new tunsrc tests and let the rest of the script
run as usual.

The bottom line is that the script needs to keep working exactly as
before when tunsrc is not supported or its dependencies are missing.
 
Thanks,
Andrea

Re: [PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[Jakub Kicinski]

On Tue, 17 Mar 2026 11:54:30 +0100 Andrea Mayer wrote:
> > @@ -819,6 +853,7 @@ test_command_or_ksft_skip ip
> >  test_command_or_ksft_skip ping
> >  test_command_or_ksft_skip sysctl
> >  test_command_or_ksft_skip grep
> > +test_command_or_ksft_skip ip6tables
> 
> This will skip the entire script if ip6tables is not present, which
> takes down the baseline tests too.
> I think a probe at startup that checks for both tunsrc support and
> ip6tables would work well here. If either is missing, we can
> just gracefully skip the new tunsrc tests and let the rest of the script
> run as usual.
> 
> The bottom line is that the script needs to keep working exactly as
> before when tunsrc is not supported or its dependencies are missing.

FWIW that's not the general guidance for networking tests.
If it's easy to handle cleanly then sure, but we should try to avoid
complicating tests with workarounds for degraded environments.

Re: [PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[Justin Iurman]

On Tue, Mar 17, 2026 at 11:54 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
>
> On Mon, 16 Mar 2026 17:29:55 +0100
> Justin Iurman <justin.iurman@6wind.com> wrote:
>
> > Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new
> > "tunsrc" feature.
> >
> > Cc: Shuah Khan <shuah@kernel.org>
> > Cc: linux-kselftest@vger.kernel.org
> > Signed-off-by: Justin Iurman <justin.iurman@6wind.com>
> > ---
> >  .../net/srv6_hencap_red_l3vpn_test.sh         | 65 ++++++++++++++-----
> >  1 file changed, 50 insertions(+), 15 deletions(-)

[snip]

> > -     # Direction hs-1 -> hs-2 (H.Encaps.Red)
> > +     # Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
> >       # - rt-2 (SRv6 End.DT46 behavior)
> >       #
> >       # Direction hs-2 -> hs-1 (H.Encaps.Red)
> >       #  - rt-4,rt-3 (SRv6 End behaviors)
> >       #  - rt-1 (SRv6 End.DT46 behavior)
> > -     setup_rt_policy_ipv4 2 1 "" 2 encap.red
> > -     setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red
> > +     setup_rt_policy_ipv4 2 1 "" 2 encap.red true
> > +     setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false
> >
> >       # create an IPv6 VPN between hosts hs-3 and hs-4
> >       # the network path between hs-3 and hs-4 traverses several routers
> >       # depending on the direction of traffic.
> >       #
> > -     # Direction hs-3 -> hs-4 (H.Encaps.Red)
> > +     # Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc)
> >       # - rt-2 (SRv6 End Behavior)
> >       # - rt-4 (SRv6 End.DT46 behavior)
> >       #
> >       # Direction hs-4 -> hs-3 (H.Encaps.Red)
> >       #  - rt-1 (SRv6 End behavior)
> >       #  - rt-3 (SRv6 End.DT46 behavior)
> > -     setup_rt_policy_ipv6 4 3 "2" 4 encap.red
> > -     setup_rt_policy_ipv6 3 4 "1" 3 encap.red
> > +     setup_rt_policy_ipv6 4 3 "2" 4 encap.red true
> > +     setup_rt_policy_ipv6 3 4 "1" 3 encap.red false
> >
> >       # testing environment was set up successfully
> >       SETUP_ERR=0
>
>
> The paths marked "true" here were testing the encap.red baseline before
> this change. They need to stay exactly as they were originally.
> Furthermore, if tunsrc is not supported by the kernel running the test,
> the ip route command with tunsrc will fail during setup() (since
> set -e is used), and the entire script dies before any test runs.

I kinda disagree here: you're not supposed to run the updated
selftests on an old kernel or with an old iproute2 version (versions
are kept aligned). And I also concur with Jakub about degraded
environments on your last comment below.

> The idea here is to avoid duplicating the entire test suite, while still
> providing dedicated test cases for the new per-route tunsrc. A reasonable
> approach could be adding the tunsrc checks as new, separate test cases
> that run after the baseline ones, leaving the existing paths completely
> untouched.
>
> For example, a dedicated test_tunsrc() function could take care of the
> whole thing for a given path: setting up the tunsrc address, installing
> the route with tunsrc, verifying the behavior, cleaning up, and finally
> restoring the original route.

Well, I actually thought that this approach would be easier, and would
specifically avoid adding too much code or having duplication. FWIW, I
don't think providing dedicated test cases for the new per-route
tunsrc really makes sense, as it's the same behavior as without
"tunsrc". It doesn't impact the encap baseline by itself, since
nothing in the selftests depends on the outer source address. I'm open
to implement what you suggest, though, it's just that I'm not sure
it's the best way forward.

What I suggest as next step: I'll ship patch #1 alone, along with the
iproute2-next companion series, so that we don't miss the merge window
and have the feature in 7.1. In parallel, we keep discussing design
choices for the selftest and ship it as soon as we settle. Would you
agree with that plan?

Cheers,
Justin

> > [snip]
> > @@ -819,6 +853,7 @@ test_command_or_ksft_skip ip
> >  test_command_or_ksft_skip ping
> >  test_command_or_ksft_skip sysctl
> >  test_command_or_ksft_skip grep
> > +test_command_or_ksft_skip ip6tables
> >
>
> This will skip the entire script if ip6tables is not present, which
> takes down the baseline tests too.
> I think a probe at startup that checks for both tunsrc support and
> ip6tables would work well here. If either is missing, we can
> just gracefully skip the new tunsrc tests and let the rest of the script
> run as usual.
>
> The bottom line is that the script needs to keep working exactly as
> before when tunsrc is not supported or its dependencies are missing.
>
> Thanks,
> Andrea

Re: [PATCH net-next v3 2/2] selftests: add check for seg6 tunsrc

[Andrea Mayer]

On Wed, 18 Mar 2026 13:29:56 +0100
Justin Iurman <justin.iurman@6wind.com> wrote:

> On Tue, Mar 17, 2026 at 11:54 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> >
> > On Mon, 16 Mar 2026 17:29:55 +0100
> > Justin Iurman <justin.iurman@6wind.com> wrote:
> >
> > > Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new
> > > "tunsrc" feature.
> > >
> > > Cc: Shuah Khan <shuah@kernel.org>
> > > Cc: linux-kselftest@vger.kernel.org
> > > Signed-off-by: Justin Iurman <justin.iurman@6wind.com>
> > > ---
> > >  .../net/srv6_hencap_red_l3vpn_test.sh         | 65 ++++++++++++++-----
> > >  1 file changed, 50 insertions(+), 15 deletions(-)
> 
> [snip]
> 
> > > -     # Direction hs-1 -> hs-2 (H.Encaps.Red)
> > > +     # Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc)
> > >       # - rt-2 (SRv6 End.DT46 behavior)
> > >       #
> > >       # Direction hs-2 -> hs-1 (H.Encaps.Red)
> > >       #  - rt-4,rt-3 (SRv6 End behaviors)
> > >       #  - rt-1 (SRv6 End.DT46 behavior)
> > > -     setup_rt_policy_ipv4 2 1 "" 2 encap.red
> > > -     setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red
> > > +     setup_rt_policy_ipv4 2 1 "" 2 encap.red true
> > > +     setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false
> > >
> > >       # create an IPv6 VPN between hosts hs-3 and hs-4
> > >       # the network path between hs-3 and hs-4 traverses several routers
> > >       # depending on the direction of traffic.
> > >       #
> > > -     # Direction hs-3 -> hs-4 (H.Encaps.Red)
> > > +     # Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc)
> > >       # - rt-2 (SRv6 End Behavior)
> > >       # - rt-4 (SRv6 End.DT46 behavior)
> > >       #
> > >       # Direction hs-4 -> hs-3 (H.Encaps.Red)
> > >       #  - rt-1 (SRv6 End behavior)
> > >       #  - rt-3 (SRv6 End.DT46 behavior)
> > > -     setup_rt_policy_ipv6 4 3 "2" 4 encap.red
> > > -     setup_rt_policy_ipv6 3 4 "1" 3 encap.red
> > > +     setup_rt_policy_ipv6 4 3 "2" 4 encap.red true
> > > +     setup_rt_policy_ipv6 3 4 "1" 3 encap.red false
> > >
> > >       # testing environment was set up successfully
> > >       SETUP_ERR=0
> >
> >
> > The paths marked "true" here were testing the encap.red baseline before
> > this change. They need to stay exactly as they were originally.
> > Furthermore, if tunsrc is not supported by the kernel running the test,
> > the ip route command with tunsrc will fail during setup() (since
> > set -e is used), and the entire script dies before any test runs.
> 
> I kinda disagree here: you're not supposed to run the updated
> selftests on an old kernel or with an old iproute2 version (versions
> are kept aligned). And I also concur with Jakub about degraded
> environments on your last comment below.
> 
> > The idea here is to avoid duplicating the entire test suite, while still
> > providing dedicated test cases for the new per-route tunsrc. A reasonable
> > approach could be adding the tunsrc checks as new, separate test cases
> > that run after the baseline ones, leaving the existing paths completely
> > untouched.
> >
> > For example, a dedicated test_tunsrc() function could take care of the
> > whole thing for a given path: setting up the tunsrc address, installing
> > the route with tunsrc, verifying the behavior, cleaning up, and finally
> > restoring the original route.
> 
> Well, I actually thought that this approach would be easier, and would
> specifically avoid adding too much code or having duplication. FWIW, I
> don't think providing dedicated test cases for the new per-route
> tunsrc really makes sense, as it's the same behavior as without
> "tunsrc". It doesn't impact the encap baseline by itself, since
> nothing in the selftests depends on the outer source address. I'm open
> to implement what you suggest, though, it's just that I'm not sure
> it's the best way forward.
> 
> What I suggest as next step: I'll ship patch #1 alone, along with the
> iproute2-next companion series, so that we don't miss the merge window
> and have the feature in 7.1. In parallel, we keep discussing design
> choices for the selftest and ship it as soon as we settle. Would you
> agree with that plan?
> 
> Cheers,
> Justin
> 

Hi Justin,

IMHO, the optimal goals should be:
1) have at least a selftest that covers the new feature;
2) re-use *if reasonable* existing selftests;
3) have selftests that run on a reasonable set of kernels and
   environments, without unreasonably increasing their complexity.

I'd prefer to have the selftest shipped together with the feature.
I think we could find a reasonable way to integrate the tunsrc checks
without overcomplicating the existing selftest.
Let me send you an idea offline so we can evaluate it together.

I certainly don't want to hold up the tunsrc feature, it's something
I find very interesting and that I also discussed at netdev 0x19 (2025).

Thanks,
Andrea