dnsmasq adds IPs to an nft set only on a fresh upstream reply; a cache
hit never refreshes the set. On Archie the :5350 instance also wedged:
TCP child processes first, then the main process, logged
'nftset ... netlink: Error: cache initialization failed: Protocol error'
on every add and stopped filling bbrkn_v4/v6 until restarted.
warm-nftset.sh now counts those errors for the main PID during the run
(journalctl _PID=) and, if any, restarts the service and warms again;
exit 1 if it still fails. The state dir defaults to /var/lib/bbrkn so the
root cron job and the deploy share one lock (LOCK_WAIT lets deploy wait).
deploy-to-gateway.sh runs the warmer right after flushing the sets,
since clients keep old IPs cached and would bypass the tunnel until the
next fresh resolve. A warm failure only warns; it does not roll back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DR7zpSsdX28T4Kn6v4jPSS
Elements in bbrkn_v4/bbrkn_v6 carry a 1d timeout and are only refreshed
when a query reaches the host dnsmasq on :5350, where the nftset=
directives are applied. Idle domains — or ones answered from the pihole
FTL cache — age out of the sets and their traffic silently falls back to
the plain WAN route instead of the tunnel.
warm-nftset.sh re-resolves every domain from the deployed 90-nftset.conf
(base + related subdomains) directly against 127.0.0.1:5350, bypassing
the FTL cache. Sourcing the domain list from the deployed config means
there is no second list to keep in sync.
Ping is off by default: packets originating on the gateway itself go
through OUTPUT, never prerouting_mangle, so they leave unmarked and
almost all time out — a misleading signal, not a real failure.
Run on the gateway via `make warm` or hourly cron. Measured: 1059
domains in ~1m45s at PARALLEL=8, v4 526->2203, v6 305->1440 elements.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
