On 8/11/26 14:19, Daniel P. Berrangé wrote:
On Tue, Aug 11, 2026 at 02:12:25PM +0200, Dion wrote:
On 7/30/26 16:45, Daniel P. Berrangé wrote:
On Mon, Jun 01, 2026 at 12:06:01AM +0200, Dion Bosschieter wrote:
Changes in v8: - Fix incompatibility issue with ebiptables driver for inet rules Inet rules in nftables are now placed on the root chains following iptables logic inside the ebiptables driver. Introducing subchains for inet caused sorting problems, subchains can accept or drop a packet which on the ebiptables driver inet rules would have been filtered out by rules that were sorted differently.
Something about this change appears to have resulted in duplicate rules for arp being added when I run the TCK test suite for MR 79.
Nice catch, fixed in v9. The create already created rules logic was not correct.
In this case:
https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/79/diffs#70796ffc376...
#nft list chain bridge libvirt_nwfilter_ethernet vnet0-out table bridge libvirt_nwfilter_ethernet { chain vnet0-out { jump vnet0-mac-out ether type ip jump vnet0-ipv4-ip-out ether type ip accept ether type arp jump vnet0-arp-mac-out ether type arp jump vnet0-arp-ip-out ether type arp accept ether type 0x8035 jump vnet0-rarp-out ether type arp accept ether type 0x0835 accept drop } }
'ether type arp accept' is twice. In the v7 patches the second instance was not there.
Tested on your libvirt-tck branch. The 2nd arp rule should disappear now.
separately, a pre-existing thing from previous versions:
https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/79/diffs?file=a03f2a...
table bridge libvirt_nwfilter_ethernet { chain vnet0-out { ether saddr 01:02:03:04:05:06 ether type arp accept ether saddr 01:02:03:04:05:06 ether type arp drop ether saddr 01:02:03:04:05:06 ether type arp drop } }
the 'ether type arp drop' rule is present twice.
Obviously both of those things are harmless as the second instance of the rule will never be reached.
So this is more of an oddity - I raise it in case it is a symptom of a more problematic bug we might have missed ?
From what I can see, this is also the case in the ebiptables output for that test:
https://gitlab.com/libvirt/libvirt-tck/-/blob/master/scripts/nwfilter/nwfilt...
#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v "^Bridge" | grep -v "^$" -p arp -s 1:2:3:4:5:6 -j accept -p arp -s 1:2:3:4:5:6 -j drop -p arp -s 1:2:3:4:5:6 -j drop
So I think that that is correct?
Or a pre-existing bug in ebtables that we never noticed. ALl those "expected output" test files are merely a dump of whatever the code was spitting out at the time they were captured.
IOW, they're merely testing that we don't regress vs some old state of nwfilter, rather than proving everything was correct :-)
Again though this example is harmless so I'm not too bothered.
The test is specifying a reject on an ethernet rule, which doesn't work on the bridge table, so ebiptables silently converts it into a drop. I copied that logic for the nftables driver. https://gitlab.com/libvirt/libvirt/-/blob/master/src/nwfilter/nwfilter_ebipt... https://gitlab.com/libvirt/libvirt-tck/-/blob/master/scripts/nwfilter/nwfilt... <rule action='drop' direction='out'> <mac srcmacaddr='1:2:3:4:5:6' srcmacmask='ff:ff:ff:ff:ff:ff' protocolid='arp'/> </rule> <rule action='reject' direction='out'> <mac srcmacaddr='1:2:3:4:5:6' srcmacmask='ff:ff:ff:ff:ff:ff' protocolid='arp'/> </rule> Kind regards, Dion