Re: [PATCH net-next 5/5] selftests: mptcp: convert iptables to nftables for mptcp_join.sh

Hello,

On 28/09/2026 10:00, netdev-bot+sashiko@kernel.org wrote:

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.

TL;DR: It looks like there are issues with NFTables, but no new version
needed here for these MPTCP patches.

If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] In endpoint_tests()
  (tools/testing/selftests/net/mptcp/mptcp_join.sh), the new rule `tcp…
- [Low] The patch removes CONFIG_NFT_COMPAT from
  tools/testing/selftests/net/mptcp/config, "since we don't need it now".

--

selftests: mptcp: convert iptables to nftables for mptcp_join.sh

This converts the iptables/ip6tables rules in mptcp_join.sh to nftables.
It keeps the same table and chain names and adds init_nftables() to set
up the tables only when a test needs them. The cBPF bytecode that matched
the ADD_ADDR and RM_ADDR suboptions is replaced with "tcp option mptcp
subtype" matching. In the config fragment, CONFIG_NFT_COMPAT is swapped
for the nft modules that are now needed.

(...)

quoted

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 18ce7136a2b0e..b16e24418e737 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh

[ ... ]

quoted

@@ -4402,12 +4372,10 @@ endpoint_tests()
 
 		# To make sure RM_ADDR are sent over a different subflow, but
 		# allow the rest to quickly and cleanly close the subflow
-		local ipt=1
-		ip netns exec "${ns2}" ${iptables} -I OUTPUT -s "10.0.1.2" \
-			-p tcp -m tcp --tcp-option 30 \
-			-m bpf --bytecode \
-			"$CBPF_MPTCP_SUBOPTION_RM_ADDR" \
-			-j DROP || ipt=0
+		local nft=1
+		ip netns exec "${ns2}" nft insert rule ip filter OUTPUT \
+			ip saddr 10.0.1.2 meta l4proto tcp \
+			tcp option mptcp subtype remove-addr drop || nft=0

[Severity: Medium]
Can this rule ever match an RM_ADDR packet on an established connection?

nft_exthdr_tcp_eval() stops at the first TCP option whose kind matches
(30 for MPTCP). The subtype check therefore only ever sees the first
MPTCP suboption:

net/netfilter/nft_exthdr.c:nft_exthdr_tcp_eval() {
    ...
	for (i = sizeof(*tcph); i < tcphdr_len - 1; i += optl) {
		optl = optlen(opt, i);

		if (priv->type != opt[i])
			continue;
		...
		return;
	}
    ...
}

Indeed, the RM_ADDR will be added in a second MPTCP option. It looks
like Netfilter doesn't handle that case. But that seems to be an issue
on the Netfilter side, rather than with the command that should work. I
will follow up with Netfilter devs. If a fix cannot be added on their
side, I will change the nft command to look at a specific offset.

Note that the command here is just to check there is no RM_ADDR sent on
the wrong side: it shouldn't catch any packets here anyway.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.