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
Path.resolve() doesn't raise on a nonexistent path — it just returns the
syntactic path unchanged — so when driver_name() ran before the radio's
netdev had enumerated (startup race with USB re-enum), it silently
returned the literal string "driver" instead of None. The loop's retry
guard (`if driver is None: retry`) never fired since "driver" is truthy,
so the bogus value was cached for the service's entire uptime and the
queue-flush wedge regex could never match real driver names — the 3rd
check added 2026-08-19 was silently inert. Fixes 2026-08-23 recurrence
where the 5GHz SSID went invisible and hostapd never got restarted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJfEELeh3ercpRBp8yYrYS
mmcli's inline "number=...,text=..." properties string breaks on plain
spaces/quotes/colons in the text — found while testing van-sms-watch.
Sidesteps that entirely by passing the message via
--messaging-create-sms-with-text=<tempfile> instead. Tested live
(multi-word text, punctuation, multi-line stdin input all delivered).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Was checked in 100644, inconsistent with the other repo scripts
(deploy.sh's install -D -m0755 masked this in practice).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Polls ModemManager for SMS on the EC25's own flash storage, appends each
inbound message to /var/log/van-sms.jsonl, pages via Pushover (shared
van-battery creds), then deletes it from modem storage so it doesn't
silently fill up. MMS can't be decoded (WAP-push notification needs the
carrier's separate MMS APN) — detected and paged as notification-only.
Wired into deploy.sh; installed/verified live on the Pi (backlog SMS
archived + paged successfully) ahead of committing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- status_text: decode the 24-bit "status" field into human-readable flag
names (e.g. "Cell Temp Low, Low Voltage") instead of raw hex, using the
bit table pulled from com.lithionics.bms's array/advanced resource (dumped
with aapt -- the app's own StatusCodeTable class references stale/wrong
resource IDs and can't be trusted for this). Applied to "status" only;
last_fault_code is a lifetime latch that accumulates many bits over time
and isn't meaningfully summarized the same way.
- Fixed the info sensors (total_consumed, firmware_version, serial_number,
etc.) showing "Unavailable" in HA a minute after connecting: they were
getting the same expire_after as the periodic telemetry sensors, but the
$info line the come from is only sent once per BLE connection, so HA's
expire timer always fired. These are retained-topic diagnostics meant to
hold their last value indefinitely; expire_after now only applies to the
periodic SENSORS group.
- STUCK_DISCOVERY_THRESHOLD 3 -> 1: restart bluetooth.service after the
first failed scan instead of waiting for three, cutting reconnect time
roughly in third. Still rate-limited via BLUETOOTH_RESTART_COOLDOWN_S.
Also removed the per-line "RAW ..." debug print (was flooding the journal).
All three changes verified live on host wan via journalctl/mosquitto_sub.
Decoded the "&" and "$" line formats from log1 by matching them against the
decompiled com.lithionics.bms app: TraceFormat/InfoFormat gate on the raw
line's first byte ('&'=trace, '$'=info) before BmsSeries.create() ever sees
the row, which is why the earlier decode (MainBmsCsParameters) never touched
them.
"&" trace lines stream continuously (enabled by our own $traceon) and carry
CAN-charger-bus fields: remaining_capacity, remaining_time, can_charger_
voltage/current, can_charger_status, can_status. These merge into the
existing periodic state message alongside the Cs telemetry.
"$" info is sent once per connection (response to $info) and never repeats:
total_consumed, last_fault_code, highest/lowest_recorded_temp, firmware_
version, aging_factor_temp/soc, serial_number. Published to its own retained
topic (van/<device_id>/info) instead of the periodic one, with its own
discovery config (entity_category: diagnostic) — so HA keeps the last known
value across BMS disconnects rather than expiring it.
Deployed and verified live on host wan: info message publishes once on
connect, state messages carry the merged fields, and 14 new HA entities
registered with correct precision.
Publishes the RV's 12V LiFePO4 house battery to HA via MQTT discovery
(pack voltage, 4 cell voltages, current, SOC, BMS/battery temp, status).
Connects over the battery's BLE HM-10 UART module (service ffe0/char
ffe1, no pairing) using bleak; protocol reverse-engineered from the
com.lithionics.bms Android app's own BLE/parsing code.
Deliberately named li3/ and van-li3-battery, not battery/van-battery —
that name is reserved for the host's own AC/UPS power-supply monitor
(different hardware, unrelated concern).
Self-heals a bluetoothd discovery-state wedge (Discovering stuck "yes",
connects failing with le-connection-abort-by-local) that shows up after
repeated failed connects to this device on the Pi's onboard adapter: the
daemon retries scan/connect internally (MQTT session and HA entities
stay up across retries) and restarts bluetooth.service itself after 3
consecutive scan failures, rate-limited to once per 5 min.
Same sibling-container pattern as HA/ESPHome. The hand-written unit used
Privileged=true, which isn't a real Quadlet key — the generator silently
drops the whole file on an unsupported key, so frigate.service was never
generated (hence `systemctl enable frigate` saying the unit doesn't exist).
Fixed with PodmanArgs=--privileged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Tails journalctl -kf for the "nvme nvmeN: I/O tag ... timeout, reset
controller" signature that crashed and corrupted the root fs on 2026-08-02
(and recurred 2026-08-04, that time self-healing). Watches a short grace
window to tell a clean self-heal from an escalation (repeated timeout or a
following ext4 error) before paging via the existing Pushover credentials,
with a live SMART/superblock snapshot in the alert body.
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>
EC25-AF GNSS wiring (udev hotplug into gpsd) plus van-gps-owntracks, a
port of the wayback-era gps_to_owntracks.py: apt-only deps (python3-gps
instead of pip-only gpsdclient, paho 2.x callback API), broker secrets
moved out of the code into /etc/van-gps/config.json (0600, seeded from
a sanitized example), gpsd host now localhost. client_id is vanq-wan —
a legacy client still holds vanq on the broker and shared IDs get
kicked in a connect/disconnect loop. Exit-on-disconnect + systemd
Restart=always is the reconnect logic.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Include the gsm device in the WAN/Uplinks table, shown as its routed
netdev with IP and metric (nmcli actions still target cdc-wdm0). New
Signal column fed by mmcli -K in the single status spawn (percent, tech,
operator). Restart = mmcli disable/enable — the EC25 MBIM plugin doesn't
support --reset — with a USB unbind/bind fallback (vendor 2c7c) when
ModemManager can't reach the modem. README: modem setup steps (Koodo
profile creation, MBIM netdev gotcha, Cockpit row).
Co-Authored-By: Claude Fable 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>
The rotating privacy address was not itself the packet-loss mechanism:
the 2026-07-13 discrimination experiment (4 flows, dual-ended capture)
showed the loss keyed to hbc's exact 5-tuple — upstream per-flow state
poisoned when the flow was created during boot/apply address churn, kept
alive forever by the 10s heartbeat cadence. Fresh flows to the same
host/port were clean; restarting hbc fixed it instantly. use_tempaddr=0
stays: it removes one source of the churn that poisons newborn flows.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuPg8vz6FmDUj4SgEJ525C
Root cause of the flow-selective IPv6 heartbeat loss investigated
2026-07-12/13: Ubuntu ships /usr/lib/sysctl.d/55-ipv6-privacy.conf with
use_tempaddr=2 system-wide. Nothing on wlan0 overrode it before this
morning's netplan fix, so the interface carried a rotating privacy
address alongside the stable one. hbc's long-lived flow eventually
straddled a temp-address deprecation event mid-flight, which looked
exactly like random upstream packet loss (in-transit, IPv6-only,
flow-selective) and cost a day of packet captures before the cause
turned out to be this default fighting the WAN config instead.
The netplan/NM ipv6.ip6-privacy=false fix already forces this per
connection, but that's a timing-dependent override racing a package
default. This makes it explicit and permanent: 99- loads after (and
wins over) 55- the next time sysctl --system runs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 07-12 IPv6 fix sat in ap/50-van-wan.yaml for a day without ever being
copied to /etc/netplan/ or applied — deploy.sh deliberately skips netplan
(applying it flaps the uplinks) so nothing caught the gap. Now it diffs
the two and prints the manual deploy commands when they disagree.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New "Clients" card lists everything on the van LAN in one table — hostname,
IP, MAC, connection (5GHz / 2.4GHz / LAN eth0 / LAN USB), signal, TX rate.
Wi-Fi rows come from the hostapd station dumps as before; wired rows from
learned bridge-FDB entries on the LAN ports (the port's own MAC is
"permanent", and FDB duplicates entries per vlan — both filtered), enriched
with IP/hostname from dnsmasq leases + neighbor table.
The per-band station tables move out of the Access Points card (which keeps
its status line + client count), and the WAN/Uplinks table now hides
unmanaged devices so the networkd-owned LAN ports don't show up as ghost
WAN rows.
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 Starlink RTL8153 gets a declarative NM profile in 50-van-wan.yaml
(replaces the auto 'Wired connection 1') with a 192.168.100.1/32 link route,
so the dish's management address stays reachable from the router and — via
the existing !br0 masquerade — from the van LAN, regardless of which WAN
holds the default route.
New Cockpit "Starlink" card queries the dish's gRPC API (:9200, get_status
via grpcurl — not packaged in apt, deploy.sh warns when missing) inside the
existing single batched spawn: online/obstructed/outage pill, alerts,
uptime, sw version, PoP latency, down/up throughput, obstruction %.
Sentinels distinguish adapter-absent / no-grpcurl / dish-unreachable.
Gotcha captured while cutting over: a WAN profile without ipv4.route-metric
makes NM re-assert its DHCP default (metric ~101) against van-failover's
enforce_route pruning every cycle; the profile metric must match (failover's
set_profile_metric does this on health transitions).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
van-thermal grows sensor kinds beyond plain temperatures: "fan" alerts when
pwmfan is commanded on (pwm > 0) but reads 0 RPM (warn on first sample, crit
if it persists — 0 RPM with pwm 0 is just the firmware idling a cool SoC),
and "undervolt" goes crit on the live rpi_volt alarm plus a sticky warn off
the firmware's latched since-boot bit, so dips shorter than the 10s sample
interval still surface once. All kinds share the existing hysteresis /
journal / Pushover machinery (fan 🌀, undervolt ⚡).
Config adds nvme Composite (65/70), rp1_adc (80/85 — the RP1 die drives all
USB/eth I/O), fan, and undervolt to the existing cpu sensor. The CSV logger
now derives per-kind columns and self-rotates when the header changes; the
Cockpit Temps card renders RPM + pwm duty and undervoltage state alongside
the temperatures.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
van-thermal fires its first sample seconds after start, and the Pi often
boots hot — order after network-online.target and retry network failures
in the Pushover send path (3 attempts, 15s apart) so that page survives
DNS not being up yet. Non-200 responses still don't retry.
The Quadlet gets StopTimeout=120: podman's default 10s window SIGKILLed
HA mid-flush and the recorder complained about an unclean sqlite shutdown
on every start. Verified clean after a full stop/start cycle.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The fixed 2 GiB ha_van allocation starved the 4 GB Pi. HA Container now
runs on the host network (http://10.42.0.1:8123): ha/homeassistant.container
installs to /etc/containers/systemd/, config in /srv/homeassistant, host
D-Bus mounted for onboard Bluetooth (needs apparmor=unconfined — Ubuntu's
dbus-daemon mediates per AppArmor label and denies AddMatch to BlueZ —
plus NET_ADMIN/NET_RAW for habluetooth adapter recovery).
Drop the VM-era plumbing: the 10.42.0.50 dhcp-host pin becomes a
host-record for 10.42.0.1, and the legacy-URL DNAT + hairpin masquerade
go away entirely. ha_van.xml retired to git history.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The backup-restore from the x86 instance left Core stopped with the
Supervisor idle and healthy-looking — no restart, download, or disk
activity, and it survived a guest reboot. The old config was minimal,
so: fresh 18.1 image, configure from scratch (old disk kept aside as
*.old-restored). Add VNC graphics + virtio-gpu while the domain was
down: the HAOS CLI runs only on the graphical console (no serial
getty), so without this there is no way into a broken guest — view it
via Cockpit's Virtual Machines page (cockpit-machines now installed).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The x86 ha_van stayed behind on wayback at the port (9bf1420 dropped
ha/ and its DNAT/lease); with the hub moved and the Pi owning
10.42.0.0/24, HA follows. New domain XML: machine=virt + AAVMF EFI,
virtio-scsi HAOS 18.1 aarch64 image, 2 GiB (data restored from an HA
full backup — the x86 qcow2 can't cross architectures). Same MAC, so
the dnsmasq pin (10.42.0.50 / "homeassistant") and the legacy
10.42.0.1:8123 DNAT + br0 hairpin port back verbatim.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Python cockpit-bridge frees spawn-pipe fds only at GC time; the Van
Router page's ~12 cockpit.spawn calls every 5s saw-toothed the bridge to
its 1024-fd soft limit, so the polkit admin-escalation spawn failed with
"Too many files open" whenever it landed near a peak.
Two-sided fix:
- vanrouter.js gathers all read-only status in ONE `sh -c` spawn per
refresh, sections delimited by @@vr:<name>@@ marker lines (~12x less
pipe churn). Mutating actions unchanged.
- cockpit-session@.service drop-in raises LimitNOFILE to 65535
(hard limit is 524288), installed by deploy.sh.
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>
Join station MACs against dnsmasq leases (IP + hostname), with the
kernel's br0 neighbor table as a fallback IP source for static-IP
clients.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vanrouter.js hardcoded the 5GHz iface; generalize to an APS list
(iface + hostapd unit + band label). The Access Points card now renders
a status line, client table, and Restart button per band, and the WAN
table excludes both AP ifaces.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Second radio (wlxd8ec5e2faa8c, RTL8822BU/rtw88), same VanLink SSID+PSK,
ch6 HT20, bridged into br0 next to the 5GHz AP. Runs as its own hostapd
instance + own watchdog so a USB wedge on one radio never darkens the
other; van-ap-watchdog now takes conf path + unit name as args (defaults
unchanged). rtw88.conf disables deep power-save (rtw89 gotcha analog)
and the driver's USB2->3 self-upgrade (USB3 noise in the 2.4GHz band —
note: dongle currently sits in a USB3 port, so it still enumerates
SuperSpeed; move to a USB2 port if 2.4GHz range disappoints).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The VM lived on libvirt's default NAT net (192.168.122.50) behind a
/etc/libvirt/hooks/network hook that inserted FORWARD accepts above
libvirt's REJECT. libvirtd restarts re-inserted its chains on top
without firing the hook, silently cutting clients off from HA.
Now the VM's NIC (virtio, was e1000) bridges into br0: pinned lease
10.42.0.50 / name 'homeassistant' via van-ap dnsmasq, mDNS discovery
works, and no firewall hook can rot. Legacy http://10.42.0.1:8123
kept working via DNAT + same-subnet hairpin masquerade. Hook, libvirt
DHCP reservation, and iptables rules removed; domain XML in ha/.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
After a USB re-enumeration the rtw89 radio can come back as a fresh DOWN
netdev, dropped from br0, while the still-running hostapd never notices and
never exits — so Restart=always never fires. hostapd_cli keeps answering
state=ENABLED off stale in-memory state, so the watchdog considered the AP
healthy and left it dark (observed 2026-07-05: AP down ~16:41 until manual
hostapd restart).
Add link_healthy(): require the netdev to be operstate=up and still a port of
its bridge, alongside the existing state=ENABLED check. That catches the wedged
case the control socket can't see.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Starlink's USB ethernet shares a hub with the rtw89 Wi-Fi adapter; when Starlink
flaps, the hub re-enumerates and tears the radio down, so hostapd loses its
interface and exits. Two stock defaults left the AP dark: Restart=on-failure
misses clean exits, and the 5-in-10s start limit makes systemd give up during a
re-enumeration storm.
- hostapd-restart.conf drop-in: Restart=always, RestartSec=5, StartLimitIntervalSec=0
so hostapd retries forever until the interface returns (verified: SIGKILL -> back
to state=ENABLED in ~7s).
- van-ap-watchdog daemon: backstop for the case systemd can't see (hostapd running
but radio wedged). Polls hostapd_cli status; restarts hostapd if the iface is
present but not ENABLED, waits it out if the iface is mid-re-enumeration.
- hostapd.conf: add ctrl_interface so the watchdog can read the real AP state.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a wired LAN port on the same 10.42.0.0/24 segment as VanLink WiFi by
bridging both into br0. The gateway IP, dnsmasq, and NAT move off the wlan name
onto br0; hostapd (not networkd) enslaves the wlan via bridge=br0, since a
station-mode wlan can't be bridged until it's in AP mode. NM leaves the wired
port unmanaged so networkd owns it. Failover/Starlink (enxd8ec5eeb3512)
untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
van-thermal already logged falling crossings to the journal but only paged
Pushover on rising ones. announce() now returns the crossing direction, and a
falling crossing pages an "all-clear" when leaving a level we'd have alerted on,
so the phone that got the rising alert also gets the recovery. thermal-config
gains the pushover_level + shared credentials_path keys. Ignore __pycache__.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two TODO Tier-1 items:
- Hardware watchdog: power/10-vanlink-watchdog.conf drop-in sets
RuntimeWatchdogSec=20s + RebootWatchdogSec=5min; deploy.sh applies it via
daemon-reexec. PID1 pets intel_oc_wdt; a >20s systemd hang hard-resets the box.
- Heartbeat / dead-man's switch: vendored hbc.yaml + hbc.service report to
hbd.wrede.pvt (UDP 50003) every 15s as user andreas, shipping cpu/mem/disk/
network/zfs metrics. The hbc binary is installed once via the heartbeat
project's installer (README §4); deploy.sh starts the service when present.
Auto-power-on-when-mains-returns: documented as a BIOS-only option (not
OS-controllable on this ZenBook) in README §3 + TODO, per decision.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
