Refreshes the USB disk (sda2) as a live boot-fallback clone of the
running root, same self-sync guard/excludes/rsync flags as the SD
script. Fixed copy-paste leftovers from sync-sd-backup.sh (SD_ROOT_PART,
mount point, and log message all still said "SD").
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJfEELeh3ercpRBp8yYrYS
The EC25/Koodo GSM connection is QMI raw-ip with an on-link /29 and no
gateway at all (nh 0.0.0.0), not a normal DHCP WAN with a temporarily
unknown gateway. enforce_route() required a gw and silently gave up
when none was found, so cellular could be reported up/healthy/preferred
in state.json while never actually getting a default route (Prefer
button had no effect since it only touches metric, not this bailout).
Now falls back to installing a gateway-less `ip route ... dev DEV`
default when the device genuinely has an IPv4 address (carrier truly
up), mirroring what NM itself would install without never-default.
Also fixes stale-route pruning to handle gateway-less old routes,
which the previous gw-only check skipped.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
van-failover is now the sole owner of default-route selection: netplan/NM
profiles get ipv4.never-default so NM's own DHCP/lease renewals stop
reinstalling competing default routes (was racing van-failover's enforce_route
on Starlink's 16s lease). set_profile_metric() also pins never-default on
NM-managed connections it doesn't own the netplan source for (e.g. cellular),
and nm_gateway() falls back to the raw DHCP4 lease's `routers` option since NM
stops populating IP4.GATEWAY once never-default is set.
Probing moved from one shared round to independent per-WAN retry scheduling,
so a flaky WAN retries on its own clock instead of dragging healthy WANs into
extra probes or throttling a failing one to the slow steady-state cadence.
config.json: probe_interval 4->60, fail/ok_threshold 3/2->2/1, single probe
URL — verified live across this reboot (cellular took ~2min after NM reported
"activated" to actually pass traffic; van-failover correctly withheld/
deprioritized the default route until then, then installed it automatically).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The SD card (mmcblk0p2) is refreshed as a live boot-fallback clone of
NVMe root after pushes, but that rsync was being hand-typed each time
and its exclude list didn't cover /etc/fstab. That let it clobber the
SD's own fstab with the NVMe's PARTUUIDs, breaking SD-only boot (only
mounts correctly if the NVMe happens to also be present). Also excludes
/etc/machine-id and /var/log so the clone doesn't inherit the NVMe's
identity/journal history.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completes the van-modem-usb-kick -> van-modem-watch swap from the
previous commit: deploy.sh was still installing/enabling the old unit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hub power-cycle recovery was proven not to work — only a physical
unplug/replug clears a cold-boot enumeration failure. Modem moved to the
Pi's native USB port as the actual fix; this just pages via Pushover if
it recurs instead of attempting a recovery that doesn't work.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Seen after moving the modem onto the new powered UGreen hub: the port
sometimes never signals a connect during boot (no descriptor-read attempt at
all in dmesg), so the hub never rescans it. Unbind/rebinding the inner hub
chip reproduces the same connect edge a physical unplug/replug does.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
STARLINK_IFACE pointed at the wrong device after the USB hub swap (was
accidentally set to the 5GHz AP dongle's interface). failover/config.json
also hardcoded the old interface name instead of being templated like the
other configs, so deploy.conf changes never reached it — switched it to
@STARLINK_IFACE@ and deploy.sh now renders it.
- 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>
- deploy.conf templates interface names/USB IDs (@TOKEN@ substitution) across
ap/* configs so a dongle swap only needs deploy.conf edited, not the repo
configs themselves; drops ap/rtw88.conf (old 2.4GHz dongle retired for the
DWA-171, which needs no such power-save override).
- failover/van-wlan-watchdog: recovers wlan0 from NM's post-boot no-secrets
wedge (a boot-time supplicant race, not a real credential failure).
- deploy.sh: warn() collects dependency/config warnings (missing python3-gps,
python3-paho-mqtt, mobile-broadband-provider-info, grpcurl, gpsd; netplan
drift; unedited example configs) into /var/lib/vanlink/deploy-warnings.json,
rendered as an amber Cockpit card so they're visible without reading deploy
output.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
NM reports a gsm connection's device as the control port (cdc-wdm0), but
IP + routes live on the wwan netdev (wwu1u2i4 on the Quectel EC25-AF), so
probes and route enforcement silently saw nothing (cellular stuck "down",
no metric). Map connection-keyed WANs through GENERAL.IP-IFACE, and let
the gateway fallback query the connection since the netdev isn't an NM
device.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With wifi + Starlink + cellular as uplinks, the onboard GbE earns its keep
as a wired LAN port instead of the metric-150 ethernet WAN: eth0 leaves
netplan/NM (added to van-ap-unmanaged.conf) and joins br0 via networkd
(23-van-lan-eth0.network), so wired clients get 10.42.0.x DHCP/DNS and NAT
exactly like Wi-Fi clients. The eth WAN is gone from van-failover's config.
Cutover notes: delete the old netplan-eth0 / stray eth0 NM profiles, then
nmcli general reload + networkctl reload/reconfigure eth0. NEVER cable this
port (or the USB LAN dongle) back into an upstream LAN — dnsmasq on br0
would serve rogue DHCP there; STP stays off, so don't cable both wired LAN
ports to the same switch either.
Co-Authored-By: Claude Fable 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>
