[PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Fernando Fernandez Mancera]

The test checks that the packets are processed by the bridge device and
not forwarded.

Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
Please keep on mind that this requires:
* https://lore.kernel.org/netfilter-devel/20250902113529.5456-1-fmancera@suse.de/
* https://lore.kernel.org/netfilter-devel/20250902113216.5275-1-fmancera@suse.de/
---
 tests/shell/features/meta_ibrhwdr.nft         |  8 ++
 .../shell/testcases/packetpath/bridge_pass_up | 83 +++++++++++++++++++
 2 files changed, 91 insertions(+)
 create mode 100644 tests/shell/features/meta_ibrhwdr.nft
 create mode 100755 tests/shell/testcases/packetpath/bridge_pass_up

diff --git a/tests/shell/features/meta_ibrhwdr.nft b/tests/shell/features/meta_ibrhwdr.nft
new file mode 100644
index 00000000..ba9b3431
--- /dev/null
+++ b/tests/shell/features/meta_ibrhwdr.nft
@@ -0,0 +1,8 @@
+# cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support")
+# v6.16-rc2-16052-gcbd2257dc96e
+table bridge nat {
+	chain PREROUTING {
+		type filter hook prerouting priority 0; policy accept;
+		ether daddr set meta ibrhwdr
+	}
+}
diff --git a/tests/shell/testcases/packetpath/bridge_pass_up b/tests/shell/testcases/packetpath/bridge_pass_up
new file mode 100755
index 00000000..f83d6159
--- /dev/null
+++ b/tests/shell/testcases/packetpath/bridge_pass_up
@@ -0,0 +1,83 @@
+#!/bin/bash
+
+# NFT_TEST_REQUIRES(NFT_TEST_HAVE_meta_ibrhwdr)
+
+rnd=$(mktemp -u XXXXXXXX)
+ns1="nft1ifname-$rnd"
+ns2="nft2ifname-$rnd"
+ns3="nft3ifname-$rnd"
+
+cleanup()
+{
+	ip netns del "$ns1"
+	ip netns del "$ns2"
+	ip netns del "$ns3"
+}
+
+trap cleanup EXIT
+
+set -e
+
+ip netns add "$ns1"
+ip netns add "$ns2"
+ip netns add "$ns3"
+
+ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2
+ip link add veth1 netns $ns3 type veth peer name veth1 netns $ns2
+ip link add br0 netns $ns2 type bridge
+
+ip -net "$ns1" link set veth0 addr da:d3:00:01:02:03
+ip -net "$ns3" link set veth1 addr de:ad:00:00:be:ef
+
+ip -net "$ns2" link set veth0 master br0
+ip -net "$ns2" link set veth1 master br0
+
+ip -net "$ns1" link set veth0 up
+ip -net "$ns2" link set veth0 up
+ip -net "$ns3" link set veth1 up
+ip -net "$ns2" link set veth1 up
+ip -net "$ns2" link set br0 up
+
+ip -net "$ns1" addr add 10.1.1.10/24 dev veth0
+ip -net "$ns3" addr add 10.1.1.20/24 dev veth1
+
+ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
+table bridge nat {
+	chain PREROUTING {
+		type filter hook prerouting priority 0; policy accept;
+		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr
+	}
+}
+
+table bridge process {
+	chain INPUT {
+		type filter hook input priority 0; policy accept;
+		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
+	}
+}
+
+table bridge donotprocess {
+	chain FORWARD {
+		type filter hook forward priority 0; policy accept;
+		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
+	}
+}
+EOF
+
+ip netns exec "$ns1" ping -c 1 10.1.1.20 || true
+
+set +e
+
+ip netns exec "$ns2" $NFT list table bridge process | grep 'counter packets 0'
+if [ $? -eq 0 ]
+then
+	exit 1
+fi
+
+ip netns exec "$ns2" $NFT list table bridge donotprocess | grep 'counter packets 0'
+if [ $? -eq 1 ]
+then
+	exit 1
+fi
+
+exit 0
-- 
2.51.0

Re: [PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Fernando Fernandez Mancera]

On 10/9/25 6:24 PM, Fernando Fernandez Mancera wrote:
> The test checks that the packets are processed by the bridge device and
> not forwarded.
> 
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> Please keep on mind that this requires:
> * https://lore.kernel.org/netfilter-devel/20250902113529.5456-1-fmancera@suse.de/
> * https://lore.kernel.org/netfilter-devel/20250902113216.5275-1-fmancera@suse.de/
> ---
>   tests/shell/features/meta_ibrhwdr.nft         |  8 ++
>   .../shell/testcases/packetpath/bridge_pass_up | 83 +++++++++++++++++++
>   2 files changed, 91 insertions(+)
>   create mode 100644 tests/shell/features/meta_ibrhwdr.nft
>   create mode 100755 tests/shell/testcases/packetpath/bridge_pass_up
> 
> diff --git a/tests/shell/features/meta_ibrhwdr.nft b/tests/shell/features/meta_ibrhwdr.nft
> new file mode 100644
> index 00000000..ba9b3431
> --- /dev/null
> +++ b/tests/shell/features/meta_ibrhwdr.nft
> @@ -0,0 +1,8 @@
> +# cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support")
> +# v6.16-rc2-16052-gcbd2257dc96e

I just noticed this version is wrong. Probably I need to wait until 
6.18-rc1 and resend this. Anyway, feedback on the test is more than 
welcome :-)

Re: [PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > +# cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support")
> > +# v6.16-rc2-16052-gcbd2257dc96e
> 
> I just noticed this version is wrong. Probably I need to wait until 
> 6.18-rc1 and resend this. Anyway, feedback on the test is more than 
> welcome :-)

No worries, this looks good!

Do you think it makes sense to also add a counter-hook in ipv4 input?

Re: [PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Fernando Fernandez Mancera]

On 10/10/25 1:37 AM, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>>> +# cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support")
>>> +# v6.16-rc2-16052-gcbd2257dc96e
>>
>> I just noticed this version is wrong. Probably I need to wait until
>> 6.18-rc1 and resend this. Anyway, feedback on the test is more than
>> welcome :-)
> 
> No worries, this looks good!
> 
> Do you think it makes sense to also add a counter-hook in ipv4 input?

I don't think so as in $ns2 the counter would be always zero, with or 
without the meta ibrhwdr rule.

Thanks!

Re: [PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> The test checks that the packets are processed by the bridge device and
> not forwarded.

OK, I think it would make sense to also check that we can do something
useful with the packet.

> +
> +ip -net "$ns1" link set veth0 up
> +ip -net "$ns2" link set veth0 up
> +ip -net "$ns3" link set veth1 up
> +ip -net "$ns2" link set veth1 up
> +ip -net "$ns2" link set br0 up
> +
> +ip -net "$ns1" addr add 10.1.1.10/24 dev veth0
> +ip -net "$ns3" addr add 10.1.1.20/24 dev veth1
> +
> +ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
> +table bridge nat {
> +	chain PREROUTING {
> +		type filter hook prerouting priority 0; policy accept;
> +		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr

While this indeed is enough to check the bridge 'redirect to input'
maybe it would make sense to also check that we can do something useful
with it?

The bridge has no ip address, so I don't really see the point why anyone
would redirect the packet locally to begin with.

> +table bridge donotprocess {
> +	chain FORWARD {
> +		type filter hook forward priority 0; policy accept;
> +		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
> +	}
> +}
> +EOF
> +
> +ip netns exec "$ns1" ping -c 1 10.1.1.20 || true
> +
> +set +e
> +
> +ip netns exec "$ns2" $NFT list table bridge process | grep 'counter packets 0'
> +if [ $? -eq 0 ]
> +then
> +	exit 1

I think it would be nice to display WHERE its failing so that someone
looking at testout.log doesn't have to re-run with added "set -x" or "echo
failed at".

To give some ideas (this isn't fleshed out):

diff --git a/tests/shell/testcases/packetpath/bridge_pass_up b/tests/shell/testcases/packetpath/bridge_pass_up
--- a/tests/shell/testcases/packetpath/bridge_pass_up
+++ b/tests/shell/testcases/packetpath/bridge_pass_up
@@ -38,14 +38,18 @@ ip -net "$ns3" link set veth1 up
 ip -net "$ns2" link set veth1 up
 ip -net "$ns2" link set br0 up
 
+ip netns exec "$ns2" sysctl -q net.ipv4.ip_forward=1
+
 ip -net "$ns1" addr add 10.1.1.10/24 dev veth0
 ip -net "$ns3" addr add 10.1.1.20/24 dev veth1
+ip -net "$ns2" addr add 10.1.1.1/24 dev br0
 
 ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
 table bridge nat {
 	chain PREROUTING {
 		type filter hook prerouting priority 0; policy accept;
-		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr
+		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr meta mark set 1
 	}
 }
 
@@ -62,9 +66,19 @@ table bridge donotprocess {
 		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
 	}
 }
+
+table ip process {
+	chain FORWARD {
+		type filter hook forward priority 0; policy accept;
+		ip protocol icmp mark 1 counter
+	}
+
+}
 EOF

ALTERNATIVELY one could check INPUT instead (no fwd sysctl)
by also doing 'ip daddr set 10.1.1.1' in bridge or ip prerouting
and then checking if the packet made it to the ip input hook.

I only ever saw 3 cases of this 'bridge hijacking' implemented
via meta ibrhwdr:

1. Push packets up to mangle them via NAT.  In most cases
people did this with br_netfilter + iptables, but it would be nice
to make sure we have a working alternative to that thing.

2. Push packet to local host/application, e.g. for TPROXY intercept.
3. Push packet to local host for forwarding/policy routing.

I think that 'it arrived in ip input or forwarding'
would be good because then the above (tproxy, nat, etc. should "just work").

But if you think checking bridge input is enough, thats fine.

Re: [PATCH nft] tests: shell: add packetpath test for meta ibrhwdr

[Fernando Fernandez Mancera]

On 10/10/25 2:46 PM, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>> The test checks that the packets are processed by the bridge device and
>> not forwarded.
> 
> OK, I think it would make sense to also check that we can do something
> useful with the packet.
> 
>> +
>> +ip -net "$ns1" link set veth0 up
>> +ip -net "$ns2" link set veth0 up
>> +ip -net "$ns3" link set veth1 up
>> +ip -net "$ns2" link set veth1 up
>> +ip -net "$ns2" link set br0 up
>> +
>> +ip -net "$ns1" addr add 10.1.1.10/24 dev veth0
>> +ip -net "$ns3" addr add 10.1.1.20/24 dev veth1
>> +
>> +ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
>> +table bridge nat {
>> +	chain PREROUTING {
>> +		type filter hook prerouting priority 0; policy accept;
>> +		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr
> 
> While this indeed is enough to check the bridge 'redirect to input'
> maybe it would make sense to also check that we can do something useful
> with it?
> 
> The bridge has no ip address, so I don't really see the point why anyone
> would redirect the packet locally to begin with.
> 

Thanks for explaining Florian, right I was trying to keep the test as 
simple as possible, of course this situation is not useful at all 
user-case wise.

>> +table bridge donotprocess {
>> +	chain FORWARD {
>> +		type filter hook forward priority 0; policy accept;
>> +		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
>> +	}
>> +}
>> +EOF
>> +
>> +ip netns exec "$ns1" ping -c 1 10.1.1.20 || true
>> +
>> +set +e
>> +
>> +ip netns exec "$ns2" $NFT list table bridge process | grep 'counter packets 0'
>> +if [ $? -eq 0 ]
>> +then
>> +	exit 1
> 
> I think it would be nice to display WHERE its failing so that someone
> looking at testout.log doesn't have to re-run with added "set -x" or "echo
> failed at".
> 
> To give some ideas (this isn't fleshed out):
> 
> diff --git a/tests/shell/testcases/packetpath/bridge_pass_up b/tests/shell/testcases/packetpath/bridge_pass_up
> --- a/tests/shell/testcases/packetpath/bridge_pass_up
> +++ b/tests/shell/testcases/packetpath/bridge_pass_up
> @@ -38,14 +38,18 @@ ip -net "$ns3" link set veth1 up
>   ip -net "$ns2" link set veth1 up
>   ip -net "$ns2" link set br0 up
>   
> +ip netns exec "$ns2" sysctl -q net.ipv4.ip_forward=1
> +
>   ip -net "$ns1" addr add 10.1.1.10/24 dev veth0
>   ip -net "$ns3" addr add 10.1.1.20/24 dev veth1
> +ip -net "$ns2" addr add 10.1.1.1/24 dev br0
>   
>   ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
>   table bridge nat {
>   	chain PREROUTING {
>   		type filter hook prerouting priority 0; policy accept;
> -		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr
> +		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr meta mark set 1
>   	}
>   }
>   
> @@ -62,9 +66,19 @@ table bridge donotprocess {
>   		ip protocol icmp ether saddr da:d3:00:01:02:03 counter
>   	}
>   }
> +
> +table ip process {
> +	chain FORWARD {
> +		type filter hook forward priority 0; policy accept;
> +		ip protocol icmp mark 1 counter
> +	}
> +
> +}
>   EOF

This changes looks good to me, let me add them to the patch and test 
them. Thank you!