Linux Netfilter development
 help / color / mirror / Atom feed
From: Fernando Fernandez Mancera <fmancera@suse.de>
To: Florian Westphal <fw@strlen.de>, Matthieu Baerts <matttbe@kernel.org>
Cc: Netfilter Devel <netfilter-devel@vger.kernel.org>,
	Netfilter Coreteam <coreteam@netfilter.org>
Subject: Re: Netfilter: match "tcp option" with the same type present multiple times
Date: Mon, 28 Sep 2026 22:56:19 +0200	[thread overview]
Message-ID: <f62b8394-9ead-45fe-bf26-998c0c822dcd@suse.de> (raw)
In-Reply-To: <arpn7_v8156iSc85@strlen.de>

On 9/28/26 3:13 PM, Florian Westphal wrote:
> Matthieu Baerts <matttbe@kernel.org> wrote:
>> Hello Netfilter devs,
>>
>> First, thank you for maintaining Netfilter in the kernel and the
>> userspace tools.
>>
>> The MPTCP selftests are switching from IPTables to NFTables, and
>> Clashiko reported that this part of a rule wouldn't match anything:
>>
>>    tcp option mptcp subtype remove-addr drop
>>
>> When an MPTCP REMOVE_ADDR suboption (type 0x30, len >=4, subtype 0x4) is
>> added to the TCP options, it is added after an MPTCP DSS option (type
>> 0x30, len >= 8, subtype 0x2). In other words, there will be two MPTCP
>> (type 30) options in the TCP options. It looks like Netfilter doesn't
>> handle that, because it stops processing other TCP options when the
>> expected type is found:
> 
> Yes, this won't work. 'tcp option X' extracts the
> option X.
> 
> I don't see how this could be fixed within the limitations of the
> architecture.  Just use bpf.
> 
>> It looks like it shouldn't stop if the wrong subtype is found, but the
>> subtype is not compared there if I'm not mistaken. Should there be a fix
>> to support this case?
> 
> I don't know how, unless one would extend the kernel to make it aware of
> mptcp, which also requires userspace to pass the suboption type to look
> for in addition to 'mptcp option'.
> 

This won't be easy neither fast but I added this to my TODO list. It 
sounds fun. Unless someone else does it first, I will take it.

>> BTW, I'm probably missing something, but adding the following doesn't
>> seem to have any effect on my side:
>>
>>    nft add table ip filter
>>    nft add chain ip filter OUTPUT \
>>      { type filter hook output priority filter; policy accept; }
>>    nft insert rule ip filter OUTPUT tcp option mptcp exists counter drop
>>
>> Same with "mptcp subtype mp-capable", other subtypes or other types like
>> "timestamp". But if I use ...
>>
>>    nft insert rule ip filter OUTPUT meta l4proto tcp counter drop
>>
>> ... then the drop is effective. Any idea what I'm missing here? :)
> 
> No idea.
> cd git/netfilter.org/nftables/tests/shell; ./run-tests.sh -k testcases/packetpath/tcp_options
> 
> passes here.
> Even tried adding 'tcp option timestamp exists...' to the test, also
> passes.
> 
> nft --debug=netlink list ruleset displays the rule like this:
> 
> inet t c 15 14
>    [ exthdr load tcpopt 1b @ 8 + 0 present => reg 1 ]
>    [ cmp eq reg 1 0x01 ]
>    [ objref type 1 name tsc ]
> 
> Linux 7.3.0-rc3+
> nftables v1.1.6 (Commodore Bullmoose #7)


  parent reply	other threads:[~2026-09-28 20:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 12:13 Netfilter: match "tcp option" with the same type present multiple times Matthieu Baerts
2026-09-28 13:13 ` Florian Westphal
2026-09-28 20:26   ` Matthieu Baerts
2026-09-28 21:08     ` Florian Westphal
2026-09-28 20:56   ` Fernando Fernandez Mancera [this message]
2026-09-28 21:22     ` Florian Westphal
2026-09-28 21:23       ` Fernando Fernandez Mancera
2026-09-28 20:54 ` Fernando Fernandez Mancera
2026-09-28 21:17   ` Fernando Fernandez Mancera
2026-09-28 21:22     ` Matthieu Baerts
2026-09-28 21:52 ` Pablo Neira Ayuso
2026-09-29  9:21   ` Matthieu Baerts
2026-09-29 10:00     ` Pablo Neira Ayuso
2026-09-29 10:40       ` Matthieu Baerts
2026-09-29 12:03         ` Pablo Neira Ayuso
2026-09-30 18:33           ` Matthieu Baerts
2026-10-06 23:29             ` Pablo Neira Ayuso
2026-10-07  8:01               ` Fernando Fernandez Mancera
2026-10-07 10:47                 ` Pablo Neira Ayuso
2026-10-07  8:17               ` Matthieu Baerts
2026-09-28 21:54 ` Jan Engelhardt
2026-09-29  9:34   ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f62b8394-9ead-45fe-bf26-998c0c822dcd@suse.de \
    --to=fmancera@suse.de \
    --cc=coreteam@netfilter.org \
    --cc=fw@strlen.de \
    --cc=matttbe@kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox