From: Florian Westphal <fw@strlen.de>
To: "Antoine C." <acalando@free.fr>
Cc: netfilter-devel@vger.kernel.org,
Pablo Neira Ayuso <pablo@netfilter.org>,
Eric Woudstra <ericwouds@gmail.com>
Subject: Re: bug report: MAC src + protocol optiomization failing with 802.1Q frames
Date: Sun, 12 Oct 2025 23:44:20 +0200 [thread overview]
Message-ID: <aOwhNIqlsbmeyTPA@strlen.de> (raw)
In-Reply-To: <2093285391.1388199126.1760302786604.JavaMail.root@zimbra62-e11.priv.proxad.net>
Antoine C. <acalando@free.fr> wrote:
> Following the mails I sent on the user mailing list, it seems that
> there is a bug occurring with the first rule below (the second is
> fine):
>
> # nft list table netdev t
> table netdev t {
> chain c {
> ether saddr aa:bb:cc:dd:00:38 ip saddr 192.168.140.56 \
> log prefix "--tests 1&2 --"
> ip saddr 192.168.140.56 ether saddr aa:bb:cc:dd:00:38 \
> log prefix "--tests 2&1 --"
> }
> }
>
> It is translated this way:
> netdev t c
> [ meta load iiftype => reg 1 ]
> [ cmp eq reg 1 0x00000001 ]
> [ payload load 8b @ link header + 6 => reg 1 ]
> [ cmp eq reg 1 0xddccbbaa 0x00083800 ]
> [ payload load 4b @ network header + 12 => reg 1 ]
> [ cmp eq reg 1 0x388ca8c0 ]
> [ log prefix --tests 1&2 -- ]
>
> The MAC source and the protocol are loaded at the same time
> then checked... but with an 802.1Q packet, it is actually
> wrong: the ethertype will be 0x8100 and the protocol (here
> IPv4, 0x0800), will be 4 bytes further. And it that case,
> the second test above will succeed because the protocol
> is loaded independently.
>
> I just tested with latest versions of libmnl/libnftnl/nft
> and I get the same behavior.
The question is what these rules should actually match, there
are no consistent semantics in nftables for bridge and
netdev families: The existing behaviour is undefined resp.
random.
Should "ip saddr 1.2.3.4" match:
Only in classic ethernet case?
In VLAN?
In QinQ?
What about IP packet in a PPPOE frame?
What about other L2 protocols?
Pablo, I can't come up with any good answer for this; I think
an explicit dissector expression is needed to populate l3 and l4
information into nft_pktinfo structure for bridge/netdev families so
"ip saddr" would only ever match plain ethernet (no vlans, no pppoe).
This also means the existing skb->protocol based dependencies
need to die resp. check for offloaded vlan headers.
Whats your take?
This is also related to Eric Woudstras work to add qinq+pppoe
automatching.
next prev parent reply other threads:[~2025-10-12 21:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-12 20:59 bug report: MAC src + protocol optiomization failing with 802.1Q frames Antoine C.
2025-10-12 21:44 ` Florian Westphal [this message]
2025-10-27 18:26 ` Antoine C.
2025-10-27 18:37 ` Florian Westphal
2025-10-27 22:40 ` Antoine C.
2025-11-06 23:46 ` Florian Westphal
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=aOwhNIqlsbmeyTPA@strlen.de \
--to=fw@strlen.de \
--cc=acalando@free.fr \
--cc=ericwouds@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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;
as well as URLs for NNTP newsgroup(s).