On 2/12/26 20:06, Daniel P. Berrangé wrote:
On Thu, Feb 12, 2026 at 07:46:51PM +0100, Dion Bosschieter wrote:
On 2/12/26 16:06, Dion Bosschieter wrote:
On 2/12/26 15:12, Daniel P. Berrangé wrote:
It is running this:
2026-02-12 11:43:22.534+0000: 2396575: debug :
virCommandRunAsync:2653 : About to run nft add rule bridge
libvirt_nwfilter_ethernet n-vnet1-rarp-out ether saddr ==
52:54:00:36:96:f0 ether daddr == ff:ff:ff:ff:ff:ff ether type 0x8035
arp operation 3 arp saddr ip 0.0.0.0/32 arp daddr ip 0.0.0.0/32 arp
saddr ether 52:54:00:36:96:f0 arp daddr ether 52:54:00:36:96:f0
accept comment '"priority=500"'
Maybe it could be that we are running different nft command versions.
kernel 6.17.8-300.fc43.x86_64 and nftables-1.1.3-6.fc43.x86_64
Can indeed reproduce with newer nfttables and kernel indeed, command
What were the original versions you were using, as I'm curious what
changed to make it start failing.
seems to succeed without the "ether type 0x8035" part, I will debug this
further and submit a new version.
Initially when spotting that line I wondered about it as well. But I
think it is the correct translation of:
It is instead _not_ the correct translation. rarp support is missing
currently.
You mean missing in nftables kmod itself ?
Im doubting if I should:
- drop rarp support seeing as it is quite an old protocol (before bootp)
throwing an error, but this might cause a lot of broken filters for
users, maybe skipping the rule silently might be better and
throwing a warning
I don't think we can break existing filters with a hard error.
Logging is a possibility, but I'm sure we'll get bug reports
if we ship 'clean-traffic' with RARP rules out of the box
which trigger warnings on every VM boot, and on every filter
rebuild.
May be we do logging, combined with removing RAPRP rules from
'clean-traffic' ?
I think that "removing" rarp from clean-traffic should be: dropping rarp
instead, as we don't know if something in a network listens on rarp.
(chances are low)
Better to be safe than sorry.
This will also result in less nft rules on each VM firewall initialization:
chain vnet6-in {
...
ether type 0x8035 jump vnet6-rarp-in
chain vnet6-out {
...
ether type 0x8035 jump vnet6-rarp-out
chain vnet6-rarp-in {
ether daddr ff:ff:ff:ff:ff:ff ether type 0x8035 @nh,48,96
0x3525400dff0f700000000 @nh,144,80 0x525400dff0f700000000 counter
packets 6 bytes 168 acc
ept comment "priority=500"
counter packets 0 bytes 0 drop comment "priority=1000"
}
chain vnet6-rarp-out {
ether daddr ff:ff:ff:ff:ff:ff ether saddr 52:54:00:df:f0:f7 ether
type 0x8035 @nh,48,96 0x3525400dff0f700000000 @nh,144,80
0x525400dff0f700000000 c
ounter packets 0 bytes 0 accept comment "priority=500"
counter packets 0 bytes 0 drop comment "priority=1000"
}
- set an arp ether type 0x806 and handle rarp statements as arp
this would mean that packets aren't matched
This feels simply wrong. Worse than not matching 'rarp' packets,
the RARP rules /would/ then incorrectly match genuine 'arp'
packets, and so cause incorrect filtering behaviour.
- trying to use payload matching:
@ll,160,16 0x0003 -> means rarp operation 3
@ll,176,48, 0x525400dff0f7 -> means rarp saddr ether 52:54:00:df:f0:f7
I am not sure how well the payload matching would work, but im willing to
give this a try.
That sounds like quite alot of work.
I think it is doable, already got the first fields to match with this:
if (insertRuleArgParamHex(fw, fwrule, vars,
&rule->p.arpHdrFilter.dataHWType,
"@nh,0,16", "") < 0)
return -1;
if (insertRuleArgParamHex(fw, fwrule, vars,
&rule->p.arpHdrFilter.dataProtocolType,
"@nh,40,16", "") < 0)
return -1;
if (insertRuleArgParamHex(fw, fwrule, vars,
&rule->p.arpHdrFilter.dataOpcode,
"@nh,48,16", "") < 0)
return -1;
Using @nh should account for when the ethernet header grows (for example
vlan tagging).
nftables then merges those arguments if it can.
Which results in an unreadable nft rule:
ether daddr ff:ff:ff:ff:ff:ff ether type 0x8035 @nh,48,96
0x3525400dff0f700000000 @nh,144,80 0x525400dff0f700000000 counter
packets 6 bytes 168 accept comment "priority=500"
IMHO if the kernel nftables maintainers decided that RARP was not
deemed neccessary to support, then there's little reason to
disagree.
Fair point
If someone comes to libvirt and complains that they absolutely
must have RARP filtering, then if their complaint is compelling
enough for us, it should also be compelling enough for the
kernel maintainers to implement proper RARP support.
So I guess I'm leaning towards issuing log messages when RARP
rules are seen, and dropping RARP rules from the default
clean-traffic filter.
I'm leaning towards, dropping it in clean-traffic, reasons being, it is
an old not used protocol, which also reduces the amount of chains, rules
and jump rules.
But support it with the @nh payload matching, mentioned above, if users
want to use rarp filtering.
With regards,
Daniel
