- Upgrade R5C from Debian to Armbian 6.18 fixes RTL8822CE 5GHz limitation
- Updated deploy.conf with Armbian's systemd network interface names:
- wlan1/wlan2 → wlp1s0 (single WiFi chip; both APs on same interface)
- eth0/eth1 → enP2p33s0/enP1p17s0 (MAC-derived naming)
- 5GHz AP now working on channel 149 with 802.11ac/ax support
- DHCP functional: devices receiving IPs from 10.42.1.10-254 range
- One test device successfully provisioned with lease at 10.42.1.66
Status: R5C AP operational, ready for production failover role
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Clarify that WIFI_5G_IFACE=wlan1 uses the built-in RTL8822CE chip on
FriendlyElec R5C with rtl88x2ce driver, not the RTL8852BU from the Pi 5.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Add GATEWAY_IP, GATEWAY_PREFIX, GATEWAY_NETWORK, DHCP_RANGE_START, and
DHCP_RANGE_END variables to deploy.conf. Update ap/21-van-br0.network,
ap/van-ap-dnsmasq.conf, and ap/nftables.conf to use @TOKEN@ placeholders
for IP configuration instead of hardcoding 10.42.x addresses.
This allows deploying the same configuration to multiple routers on
different networks (e.g., Pi 5 on 10.42.0.x and R5C on 10.42.1.x) by
simply editing deploy.conf before running ./deploy.sh.
Co-Authored-By: Claude Haiku 4.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>
andreasandClaude Haiku 4.5
Andreas Wrede