On 2/12/26 16:06, Dion Bosschieter wrote:
On 2/12/26 15:12, Daniel P. Berrangé wrote:
On Thu, Feb 12, 2026 at 02:40:10PM +0100, Dion Bosschieter wrote:
On 2/12/26 13:54, Daniel P. Berrangé wrote:
On Tue, Feb 10, 2026 at 11:16:24AM +0100, Dion Bosschieter wrote:
This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that eventually it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another.
The first 2 patches are moving of functions and renames, meant to decouple nwfilter from the currently only existing ebiptables driver.
I've pushed these first 2 patches with my suggested changes on the 2nd patch, since they don't need to be held up.
The 3rd patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 4th patch.
The last patch introduces unit testing of the new nftables driver.
So how are you testing the nwfilter driver operation ?
I'm using the 'clean-traffic' filter on a test VM, and it is still failing for the same reasons I reported against v2:
Im using the clean-traffic filter from the repo.
2026-02-12 11:43:22.544+0000: 2396575: debug : virCommandRun:2499 : Result fatal signal 1, stdout: '' stderr: 'Error: conflicting statements 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"
If I run this command locally on an already existing chain, without the comment part, it runs without throwing that error.
the ether address matches are repeated twice with inconsistent matches and different syntax eg
ether saddr == 52:54:00:36:96:f0 ether daddr == ff:ff:ff:ff:ff:ff
vs
saddr ether 52:54:00:36:96:f0 daddr ether 52:54:00:36:96:f0
the 'daddr' different is presumably what it does not list
They are not the same, in the way that the 2nd ether filter arguments are prefixed with "arp"
arp saddr ether 52:54:00:36:96:f0 arp daddr ether 52:54:00:36:96:f0
Would it be possible to send the full command output, so I can replay that and find out which command is throwing that error?
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 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. 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 - set an arp ether type 0x806 and handle rarp statements as arp this would mean that packets aren't matched - 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. Thoughts?
ebtables -A I-vnet1-rarp -p RARP -s 52:54:00:df:f0:f6 -d Broadcast -- arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp- mac-src 52:54:00:df:f0:f6 --arp-mac-dst 52:54:00:df:f0:f6 -j ACCEPT
Thanks!