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
