On Tue, Aug 11, 2026 at 03:28:20PM +0200, Dion wrote: > 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#70796ffc376abc3b8622d758d9fd12ad7707fd19_0_18 > > > > > > > > > > > > #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=a03f2a185704e2a983a110a6868a9d31a0ed47f4#a03f2a185704e2a983a110a6868a9d31a0ed47f4_0_35 > > > > > > > > > > > > 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/nwfilterxml2ipebtablesout/target-test.fwall?ref_type=heads#L52 > > > > > > #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_ebiptables_driver.c#L2113 > > https://gitlab.com/libvirt/libvirt-tck/-/blob/master/scripts/nwfilter/nwfilterxml2xmlin/target-test.xml?ref_type=heads#L50 > > <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>
Ok, good, so this is totally normal expected behaviour. 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 :|
