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>
Kind regards,
Dion
