On 3/27/26 17:58, Daniel P. Berrangé wrote:
On Mon, Feb 16, 2026 at 11:42:36AM +0100, Dion Bosschieter wrote:
Unsupported nwfilter features (for now): - STP filtering - Gratuitous ARP filtering - IPSets (potential future support via nft sets)
IPSets via nft sets could work if the user predefines the nft sets in the table where they are going to be referenced. This requires the user to create the libvirt table first before starting libvirt. That is not ideal, but could be a solution.
- Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions
I should take a 2nd look at changing the _inet table to an inet table type, this way we can support reject and be more compatible with ebiptables.
What are your thoughts on these gaps ?
Looking at what worked for adding rarp support, I think the same can be done for STP, it requires a bit of, to see if the rules indeed match.
The Gratuituous ARP gap triggers a warning in libvirt-tck tests.
I finally was able to get garp support working, this also requires a bit of work and is not pretty. I'll describe below what solution seems to work. Tested by sending garp traffic using arping -I br0 -A 192.168.1.1 nftables nft command doesn't support field to field matching a simple arp saddr ip == arp daddr ip, would otherwise suffice. From ebtables man page: [!] --arp-gratuitous Checks for ARP gratuitous packets: checks equality of IPv4 source address and IPv4 destination address inside the ARP header. Something that could work though is creating an nftables concatenation set: { type ipv4_addr . ipv4_addr } Creating 1 set to match against, would mean we will have list all ipv4 ips in that set. That is not a solution. Creating 4 sets to match against combined with netmasking would however work. garp-1 { 0.0.0.0 . 0.0.0.0, 1.0.0.0 . 1.0.0.0, ... garp-2 { 0.0.0.0 . 0.0.0.0, 0.1.0.0 . 0.1.0.0, ... garp-3 { 0.0.0.0 . 0.0.0.0, 0.0.1.0 . 0.0.1.0, ... garp-4 { 0.0.0.0 . 0.0.0.0, 0.0.0.1 . 0.0.0.1, ... For full sets, see: https://gist.github.com/dionbosschieter/01665ef03d19950c37e8231bd00d1736 And finally the garp rule: arp saddr ip & 255.0.0.0 . arp daddr ip & 255.0.0.0 @garp-1 arp saddr ip & 0.255.0.0 . arp daddr ip & 0.255.0.0 @garp-2 arp saddr ip & 0.0.255.0 . arp daddr ip & 0.0.255.0 @garp-3 arp saddr ip & 0.0.0.255 . arp daddr ip & 0.0.0.255 @garp-4 counter packets 3 bytes 132 accept comment "priority=-500" I can add that the garp sets get added to the _ethernet table. After that adding the rule itself is trivial. This seems to work as the counter increases when running the arping command mentioned above. Thoughts on this solution?
I don't think we need to block for these, as the new driver is already functional enough to be useful.
With regards, Dion