gluon-nftables-limit-arp: limit each client device separately

The migration collapsed the per-device rate limit into a single limit
statement, which keeps one bucket for the whole rule - all client devices
shared it, so a single noisy device used up the budget of every other one.
The package documents a limit per device.

ebtables kept a bucket per rule, which is why the daemon added one rule per
address. The rules are static here, so use a dynamic set keyed on the
source address instead: every address gets its own bucket. The node-wide
limit stays a plain limit statement, as it was a single rule before too.

The limited address is the ethernet source, as in the ebtables ruleset, not
the ARP sender hardware address.

Requests for a target in the DAT cache now return early instead of being
excluded in every rule, which keeps them out of the counting as documented.
The interface matches that were commented out inside the chain are gone -
the rule jumping into it already matches on them.

Author: maurerle

nftables-migration-notes.md

@@ -139,6 +139,27 @@ Worst case recovery latency is one poll interval (30s), during which the rate
 limit does not apply to already-known addresses. `gluon-radv-filterd` has the
 same problem and handles it the same way, see below.
 
+### Per-device ARP rate limiting
+
+ebtables keeps a separate rate limit bucket per rule, so `gluon-arp-limiter`
+could give every client device its own by adding one rule per address to
+ARP_LIMIT_TLCHECK. A generated nftables ruleset cannot do that - the rules are
+static and only the sets are driven by the daemon - and a plain `limit`
+statement keeps a single bucket for the whole rule, which all devices would
+then share.
+
+The per-device limit is therefore a dynamic set keyed on the source address
+(`add @arplimit_rate { ether saddr limit rate over 6/minute burst 50 packets }`),
+which gives each address its own bucket. The node-wide 1/second limit stays a
+plain `limit` statement, as it was a single ebtables rule too.
+
+Both limits apply, as before and as the package documentation describes: a
+known device passes at most 6 requests per minute, and the node as a whole at
+most one per second.
+
+The limited address is the ethernet source (ebtables' `--source`), not the ARP
+sender hardware address the migration had used.
+
 ### Router advertisement filtering
 
 `gluon-radv-filterd` drove an ebtables chain with a DROP policy: it flushed
@@ -193,9 +214,6 @@ knowing about when reviewing the rest:
 
 ## Open points
 
-- The per-MAC ARP rate limit is still a single chain-wide bucket, and the
-  interface matches in `limit_arp_chain.nft` are commented out, so the chain
-  matches more broadly than the ebtables original did.
 - fw4's set of valid include positions could not be verified against its
   source, which is fetched at build time rather than checked in. `chain-pre`,
   `chain-post`, `table-post` and `ruleset-pre` are used on the strength of the

package/gluon-nftables-limit-arp/files/lib/gluon/nftables/limit_arp_chain.nft

@@ -1,3 +1,6 @@
+# Addresses of client devices, taken from the batman-adv translation table,
+# and target addresses present in the batman-adv DAT cache. Both are
+# maintained by gluon-arp-limiter.
 set limitmac {
 	type ether_addr
 }
@@ -6,56 +9,29 @@ set datips {
 	type ipv4_addr
 }
 
-# Rewrite arp packet target hardware address if target protocol address matches a given address.
-# input meta iifname enp2s0 arp ptype 0x0800 arp htype 1 arp hlen 6 arp plen 4 @nh,192,32 0xc0a88f10 @nh,144,48 set 0x112233445566 accept
+# One rate limit per client device. A plain limit statement keeps a single
+# bucket for the whole rule, which all devices would then share; keying a
+# dynamic set on the source address gives each of them its own.
+set arplimit_rate {
+	type ether_addr
+	size 1024
+	flags dynamic,timeout
+	timeout 5m
+}
 
-# chain('ARP_LIMIT', 'DROP')
 chain arplimit {
-	# obrname "br-client" \
-	# oifname "bat0" \
-	# arp operation request \
-	# counter
+	# Requests for a target in the DAT cache are answered locally and never
+	# reach the mesh, so they are neither counted nor limited.
+	arp ptype 0x0800 arp plen 4 arp daddr ip @datips return
 
-	# match everything which will land on bridge br-client
-	# protocol type: ipv4
-	# hardware type: ethernet
-	# hardware address length: 6 byte mac
-	# protocol address length: 4 byte ipv4
-	# arp request
-	# source address is mac to be limited
-	# target address is not in DAT
-	# we're over the limit
-	# count
-	# obrname "br-client" \
-	# oifname "bat0" \
-	arp ptype 0x0800 \
-	arp htype 1 \
-	arp hlen 6 \
-	arp plen 4 \
-	arp operation request \
-	arp saddr ether @limitmac \
-	arp daddr ip != @datips \
-	limit rate over 6/minute burst 50 packets \
-	counter \
-	drop
+	# Known client devices are allowed six requests per minute each.
+	ether saddr @limitmac \
+		add @arplimit_rate { ether saddr limit rate over 6/minute burst 50 packets } \
+		counter \
+		drop
 
-	# obrname "br-client" \
-	# oifname "bat0" \
-	arp ptype 0x0800 \
-	arp htype 1 \
-	arp hlen 6 \
-	arp plen 4 \
-	arp operation request \
-	arp saddr ether != @limitmac \
-	arp daddr ip != @datips \
+	# On top of that, the node as a whole passes one request per second.
 	limit rate over 1/second burst 50 packets \
-	counter \
-	drop
+		counter \
+		drop
 }
-
-# chain('ARP_LIMIT_DATCHECK', 'RETURN')
-# %s ARP_LIMIT_DATCHECK -p ARP --arp-ip-dst %s -j mark --mark-or 0x2 --mark-target RETURN
-
-# chain('ARP_LIMIT_TLCHECK', 'RETURN')
-# %s ARP_LIMIT_TLCHECK --source %s --limit 6/min --limit-burst 50 -j RETURN"
-# %s ARP_LIMIT_TLCHECK (add ? "2" : "") --source %s -j DROP