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' ? > - 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. IMHO if the kernel nftables maintainers decided that RARP was not deemed neccessary to support, then there's little reason to disagree. 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. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
