[BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Michal Soltys]

Hi,

While testing the behavior of early filtering in netdev / ingress, I 
noticed something that possibly looks like a bug.

Consider following and interface with one vlan, e.g.

ip add add 10.0.0.1/24 dev eno1
ip li add li eno1 name v250 type vlan id 250
ip add add 10.10.10.1/24 dev v250
ip li set eno1 up
ip li set v250 up


Now consider following simple nft setup:

nft add table netdev efil
nft add chain netdev efil edev { hook ingress type filter device eno1 
priority filter; }
nft add rule netdev efil edev ether type ip icmp type echo-request counter
nft add rule netdev efil edev ether type vlan icmp type echo-request counter
nft add rule netdev efil edev icmp type echo-request counter

These will be listed by nft ruleset list as such:
table netdev efil {
         chain edev {
                 type filter hook ingress device "eno1" priority filter; 
policy accept;
                 icmp type echo-request counter packets 0 bytes 0
                 ether type 8021q icmp type echo-request counter packets 
0 bytes 0
                 icmp type echo-request counter packets 0 bytes 0
         }
}

Note that the first rule omits the "ether type ip" as if it was 'ip' 
family instead of 'netdev'. So the 1st and the 3rd are listed the same - 
but they work differently.

The first rule will only count plain ip payload, the 2nd rule will count 
only vlan payload, the 3rd will count both. So after 1 ping to 
10.10.10.1 and 1 ping to 10.0.0.1, the effect would be:

table netdev efil {
         chain edev {
                 type filter hook ingress device "eno1" priority filter; 
policy accept;
                 icmp type echo-request counter packets 1 bytes 84
                 ether type 8021q icmp type echo-request counter packets 
1 bytes 84
                 icmp type echo-request counter packets 2 bytes 168
         }
}

Furthermore it seems it's impossible to return to such ruleset via:

- nft list ruleset >rules
- flush tables
- nft -f rules

As this time the 1st and the 3rd rule actually will be identical both 
visually and functionally, omitting 'ether type ip' check completely.

Re: [BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Pablo Neira Ayuso]

Hi,

Would you file a bug to netfilter's bugzilla so it is possible to
follow track of this issue?

Thanks.

On Mon, Feb 23, 2026 at 03:57:28PM +0100, Michal Soltys wrote:
> Hi,
> 
> While testing the behavior of early filtering in netdev / ingress, I noticed
> something that possibly looks like a bug.
> 
> Consider following and interface with one vlan, e.g.
> 
> ip add add 10.0.0.1/24 dev eno1
> ip li add li eno1 name v250 type vlan id 250
> ip add add 10.10.10.1/24 dev v250
> ip li set eno1 up
> ip li set v250 up
> 
> 
> Now consider following simple nft setup:
> 
> nft add table netdev efil
> nft add chain netdev efil edev { hook ingress type filter device eno1
> priority filter; }
> nft add rule netdev efil edev ether type ip icmp type echo-request counter
> nft add rule netdev efil edev ether type vlan icmp type echo-request counter
> nft add rule netdev efil edev icmp type echo-request counter
> 
> These will be listed by nft ruleset list as such:
> table netdev efil {
>         chain edev {
>                 type filter hook ingress device "eno1" priority filter;
> policy accept;
>                 icmp type echo-request counter packets 0 bytes 0
>                 ether type 8021q icmp type echo-request counter packets 0
> bytes 0
>                 icmp type echo-request counter packets 0 bytes 0
>         }
> }
> 
> Note that the first rule omits the "ether type ip" as if it was 'ip' family
> instead of 'netdev'. So the 1st and the 3rd are listed the same - but they
> work differently.
> 
> The first rule will only count plain ip payload, the 2nd rule will count
> only vlan payload, the 3rd will count both. So after 1 ping to 10.10.10.1
> and 1 ping to 10.0.0.1, the effect would be:
> 
> table netdev efil {
>         chain edev {
>                 type filter hook ingress device "eno1" priority filter;
> policy accept;
>                 icmp type echo-request counter packets 1 bytes 84
>                 ether type 8021q icmp type echo-request counter packets 1
> bytes 84
>                 icmp type echo-request counter packets 2 bytes 168
>         }
> }
> 
> Furthermore it seems it's impossible to return to such ruleset via:
> 
> - nft list ruleset >rules
> - flush tables
> - nft -f rules
> 
> As this time the 1st and the 3rd rule actually will be identical both
> visually and functionally, omitting 'ether type ip' check completely.
> 

Re: [BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Michal Soltys]

On 2/23/26 8:09 PM, Pablo Neira Ayuso wrote:
> Hi,
> 
> Would you file a bug to netfilter's bugzilla so it is possible to
> follow track of this issue?
> 
> Thanks.

Will do - I've sent a request to bugzilla-account@ to create an account.

Re: [BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Michal Soltys]

On 2/23/26 8:09 PM, Pablo Neira Ayuso wrote:
> Hi,
> 
> Would you file a bug to netfilter's bugzilla so it is possible to
> follow track of this issue?
> 
> Thanks.

Done.
https://bugzilla.netfilter.org/show_bug.cgi?id=1831

Re: [BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Florian Westphal]

Michal Soltys <msoltyspl@yandex.pl> wrote:
> While testing the behavior of early filtering in netdev / ingress, I 
> noticed something that possibly looks like a bug.

Yes, this is a bug, both in nftables and in the tests/py/netdev
directory, at least one of the existing files needs to be expanded
to trigger this bug for regression testing.

Not sure if I can get to it this week but I will put it on my todo list
in case noone else can pick this up.

Re: [BUG] "ether type ip" forgotten/implied when listing rules for 'netdev' family

[Michal Soltys]

On 2/23/26 8:24 PM, Florian Westphal wrote:
> Michal Soltys <msoltyspl@yandex.pl> wrote:
>> While testing the behavior of early filtering in netdev / ingress, I
>> noticed something that possibly looks like a bug.
> 
> Yes, this is a bug, both in nftables and in the tests/py/netdev
> directory, at least one of the existing files needs to be expanded
> to trigger this bug for regression testing.
> 
> Not sure if I can get to it this week but I will put it on my todo list
> in case noone else can pick this up.

For the record, this also happens with constructs such as:

nft add rule netdev efil edev ether type vlan meta protocol ip6 tcp 
dport 12345 counter

or

nft add rule netdev efil edev ether type vlan meta protocol ip tcp dport 
12345 counter

So if we e.g. wanted to catch a vlan packet with some specific payload. 
This will be simplified (during nft list ruleset) to just:

meta protocol ip6 tcp dport 12345 counter packets 0 bytes 0
meta protocol ip tcp dport 12345 counter packets 0 bytes 0

The rules will function correctly if added via add rule, but will 
analogously ignore the payload after reloading via -f

I'll add that variation to the bug report as well.