- deploy.conf: DNS_RESOLVERS, always 1.1.1.1/8.8.8.8, never a WAN's own
DHCP/RA-provided servers (previously whatever Wapana handed out).
- ap/99-van-router-dns.conf: global resolved config (fixed DNS, Domains=~.,
global MulticastDNS=yes — a prerequisite for any per-link mDNS to work at
all, not just an on/off toggle).
- failover/60-van-wan-dns: NM dispatcher that strips each WAN's DNS/search-
domain and disables its mDNS via resolvectl on every connect/lease event
(NM's own ipv4/ipv6.ignore-auto-dns can't be set as a config-file default —
confirmed rejected as an unknown key — so this enforces it directly
instead), retried over ~5s to beat NM's own async DNS commit. Also logs
what each WAN advertised, never used, to /run/van-wan-dns/.
- ap/21-van-br0.network: MulticastDNS=yes, scoped to the van's own LAN only
— .local/mDNS now resolves for ESPHome and other LAN devices without
leaking mDNS onto Wapana/Starlink/cellular.
- dns/: ZeroTier-managed DNS (zt.wrede.pvt) made reproducible — installed
the official zerotier-systemd-manager package (verified against upstream
checksums), additive to the above so *.zt.wrede.pvt keeps resolving over
the overlay independent of WAN.
- ha/esphome.container: ESPHome dashboard as a sibling Podman Quadlet to
Home Assistant, same host-network/config-volume pattern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The USB hub (5GHz + 2.4GHz AP dongles, Starlink + LAN RTL8153s) moves over
from wayback; MAC-derived wlx*/enx* names travel with it, so hostapd/
networkd/cockpit configs are unchanged. Pi diffs only: failover WAN list
(wlan0 wifi 100, eth0 150, starlink USB 200, Koodo 300), cpu_thermal
sensor, bcm2835 watchdog 10s, no HA DNAT/lease, and deploy.sh drops
battery/lid/heartbeat/ZT-dns. Netplan reference in ap/50-van-wan.yaml.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The previous fix (RequiredForOnline=no on the ZT link) could not work and the
~2min boot stall returned. systemd-networkd-wait-online (systemd 255) only
declares the network online when at least one managed, online-eligible link
goes routable. networkd here manages only the AP (wlxc…, local-only) and the ZT
overlay — and with the ZT link also marked RequiredForOnline=no (on top of the
AP link that already was), wait-online had zero candidate links and could never
satisfy "online", burning its full 120s timeout every boot. Journal confirmed:
"Timeout occurred while waiting for network connectivity" at exactly +120s,
gating network-online.target → zerotier-one (the recovery path).
Mask systemd-networkd-wait-online entirely — neither networkd link is a real
uplink, and real uplink readiness is already covered by NetworkManager-wait-online.
Wire the mask into deploy.sh, delete the now-dead RequiredForOnline=no drop-in,
and correct README §3/§5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
systemd-networkd-wait-online waits for every managed networkd link to go
routable. The ZT link ztuga7c2kh only appears once zerotier-one starts, but
zerotier-one is ordered After=network-online.target — so wait-online blocked
on the not-yet-existing link until its 120s timeout, adding ~2min to every
boot and delaying ZeroTier (the recovery path).
Add a RequiredForOnline=no drop-in so the overlay link is excluded from the
gate; real uplink readiness is already covered by NetworkManager-wait-online
(networkd owns only the AP + ZT links here, neither a true uplink). Wire it
into deploy.sh and document the loop in README §3/§5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Andreas WredeandClaude Sonnet 5