On Mon, 28 Sep 2026 23:17:59 +0200 Matthieu Baerts wrote:
quoted
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.
After a discussion with Netfilter devs, it looks like a fix will not be
easy to have. Yet, I wonder if it wouldn't be better to apply this patch
like that (it doesn't break things), and have an explicit follow-up/fix
to document this issue somehow.
@Hangbin: do you plan to look at a fix for that? I guess a raw payload
looking at the same fields as what the previous cBPF rule was doing
would be enough.
Don't hesitate to fix the "low" priority comments as well.
https://lore.kernel.org/all/20260926-net-next-mptcp-misc-feat-7-4-v1-0-67af4ab37406@kernel.org/T/#u (local)
-110, let me take the kernel patches for now, repost the selftests
please, in whatever form you decide to have them.