netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).