claude-memory/pi-wan-port.md

name, description, metadata

name	description	metadata
pi-wan-port	Pi 4 host 'wan' runs the live vanlink router stack (branch wan of its own ~/vanlink clone); USB hub moved over 2026-07-06, both AP bands beaconing.	node_type type originSessionId memory project 2a8455f6-a504-4683-b972-73a2930ce600

Ported 2026-07-06: Raspberry Pi 4B ("wan", Ubuntu 26.04 aarch64) runs the full wayback-campervan-ap stack from branch wan of its own ~/vanlink git clone (commits 9bf1420+). Plan: the USB hub moves from wayback to the Pi — AP dongles (wlxc83a35a4ee55 5GHz, wlxd8ec5e2faa8c 2.4GHz), Starlink RTL8153 (enxd8ec5eeb3512), LAN RTL8153 (enx00e04c331140). MAC-derived names travel with the hardware, so the whole AP/ bridge/cockpit config ported verbatim; hostapd(+2g) spin in Restart=always until the radios enumerate, then the Pi lights up as the van router with zero further action.

• Access: SSH andreas@192.168.6.128 (eth0) / .140 (wlan0), passwordless sudo. IPs changed from .138/.213 at cutover — NM's DHCP client-id differs from networkd's, so the Pi drew fresh leases. Suggest DHCP reservations on the home server if stability wanted. Cockpit https://192.168.6.128:9090 (Van Router plugin installed).
• WANs (NM-owned via netplan ap/50-van-wan.yaml, renderer NetworkManager): wlan0 wifi "Wapana" metric 100 (preferred), eth0 metric 150, starlink USB 200 (absent), Koodo gsm 300 (absent). cloud-init network config disabled (/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg); old 50-cloud-init.yaml removed.
• Pi-specific diffs (all in the wan branch): thermal sensor cpu_thermal (no label → temp1 fallback; warn 80 / crit 85; idles ~68-73°C), watchdog RuntimeWatchdogSec=10s (bcm2835_wdt max 15s — 20s would fail), no HA DNAT/lease, deploy.sh drops battery/lid/heartbeat/ZT-dns and tolerates absent AP radios.
• Gotcha (cutover): after netplan switched wlan0 to NM, netplan-wpa-wlan0.service kept running and held the interface — NM logged "wpa_supplicant couldn't grab this interface" 5x then gave up permanently (device stuck "unavailable"). Fix: stop + disable netplan-wpa-wlan0.service, then restart NetworkManager (a plain nmcli device connect won't revive a given-up device).
• Verified: unattended cold boot brings up everything (services, watchdog armed, NM WANs, failover steering metrics, br0 10.42.0.1, nft NAT, Cockpit 200).
• Hub moved (observed evening 2026-07-06): AP radios + LAN adapter are on the Pi and live — hostapd (VanLink 5GHz ch149/80MHz) and hostapd-2g (ch6) both active/beaconing, enx00e04c331140 present. Starlink RTL8153 (enxd8ec5eeb3512) still absent.
• Cockpit EMFILE fix (2026-07-06): the Python cockpit-bridge frees spawn-pipe fds only at GC; the Van Router page's ~12 spawns/5s saw-toothed the bridge to its 1024-fd limit → "Too many files open" on admin escalation. Fixed in the wan branch: vanrouter.js batches all status reads into ONE sh -c spawn per refresh, plus a cockpit-session@.service drop-in (LimitNOFILE=65535) installed by deploy.sh.
• Open items now the hub moved: HA VM stays on wayback bridged to its br0 10.42.0.50 — becomes unreachable from clients once the Pi owns 10.42.0.0/24 (needs a new home or new plumbing); ZT managed route 10.42.0.0/24 → wayback must move if the Pi joins ZeroTier; heartbeat (hbc) + ZeroTier not installed; Pushover creds not filled in (/etc/van-battery/pushover.json seeded with placeholders — path kept for van-thermal parity).