Fixed three critical issues preventing DHCP from working:
1. Config file rendering: Placeholders (@GATEWAY_IP@, etc.) weren't being
substituted. Using direct heredoc writes instead of sed for reliability.
2. Service dependency blocking: van-br0-setup was blocked waiting for
hostapd.service to start, preventing bridge members from being added.
Changed to only depend on systemd-networkd so boot completes.
3. Port 53 conflict: systemd-resolved was listening on port 53, blocking
dnsmasq from binding. Disabled DNS in systemd-resolved config.
R5C now operational:
- 5GHz AP on channel 149
- Bridge: 10.42.1.1/24 with enP2p33s0 + wlp1s0
- DHCP: 10.42.1.10-254 (4+ active leases)
- van-ap-dnsmasq service: running and serving DHCP
- hostapd-2g: disabled (interface wlx3c3332002066 not available)
Disabled hostapd-2g.service until D-Link RTL8188GU is fixed (stuck in CDROM mode).
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Updated hostapd.conf to run 5GHz AP on channel 149 with MT7925E (mt76 driver).
Now supports full 802.11ac (VHT) and 802.11ax (WiFi 6) capabilities.
Also fixed deploy.sh rendering issue that left unsubstituted placeholders in
network configs, causing Ethernet flaps. Configs are now properly deployed.
- hw_mode=a (5GHz), channel=149
- VHT and HE (WiFi 6) capabilities enabled
- Proper bridge configuration with gateway IP 10.42.1.1/24
- DHCP range 10.42.1.10-254 verified working
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
RTL8188GU WiFi adapter (0bda:1a2b) ships in CDROM mode on initial connection.
Install usb-modeswitch package and config to automatically switch to network
mode on boot.
Required for 2.4GHz AP to function when using D-Link DWA-171 or similar
RTL8188GU-based adapters.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Move python3-gps, python3-bleak to REQUIRED_PACKAGES (needed for van-li3-battery,
van-gps-owntracks). Add modemmanager to REQUIRED_PACKAGES (provides mmcli for
van-sms-* services).
Deploy will now fail if these packages are missing, preventing silent failures
when GPS or SMS services are needed.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Replaced RTL8822CE with Mediatek MT7925E PCIe WiFi card. The mt76 driver
(MT7925E) properly supports AP bridge mode, unlike rtw88 (RTL8822CE).
R5C is now PRODUCTION-READY:
- 5GHz AP on channel 149 with 802.11ac/ax support
- WiFi clients bridge properly and receive DHCP
- Ethernet failover fully functional
- NAT/routing configured
RTL8822CE limitation: bridging in AP mode not supported by rtw88 driver.
MT7925E solution: mt76 driver stack supports full bridge forwarding.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
dnsmasq was failing to start or staying inactive because it was starting
before the bridge members were added. Updated van-ap-dnsmasq.service to
depend on van-br0-setup.service, ensuring the bridge is ready before
dnsmasq binds to br0.
Fixes: DHCP not provisioning addresses on boot.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
systemd-networkd Bridge= directive wasn't reliably adding interfaces to br0
on Armbian. Created persistent systemd service to ensure enP2p33s0 and wlp1s0
are added to the bridge after boot, maintaining 10.42.1.0/24 network.
This ensures the gateway bridge stays configured even after R5C reboots.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- 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>
FriendlyElec R5C RTL8822CE WiFi chip does not support 5GHz AP mode.
Both wlan0 and wlan1 locked to 2.4GHz-only (mode 2) by firmware/driver.
Tested:
- Channel 149 (5GHz): fails with 'mode (2) not found'
- Channel 36 (5GHz): fails with 'mode (2) not found'
- Both wlan0 and wlan1: same limitation
- Regulatory domain persistence doesn't change mode
Solution: Configure hostapd for 2.4GHz (hw_mode=g, channel 6)
- VanLink2 now on wlan1, 2.4GHz channel 6
- VanLink2-2G still on wlan2, 2.4GHz channel 6
- Both working stably
R5C not recommended for 5GHz AP use; consider Pi 5 or other board
if 5GHz dual-band AP is required.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: wlan1 regulatory domain not set on boot, defaults to 2.4GHz-only mode,
preventing channel 149 (5GHz) from being available. hostapd fails on startup.
Solution:
1. Modified regdomain.service to:
- Run BEFORE hostapd/hostapd-2g services (Before= directive)
- Run earlier in boot (After= sysinit.target)
- RemainAfterExit=yes to persist setting
2. Added 80-regdomain.rules udev rule:
- Triggers on regulatory device changes
- Executes 'iw reg set CA' automatically
3. Added hostapd drop-in config:
- Explicitly requires regdomain.service
- Adds Wants= to ensure it starts
This ensures the regulatory domain is set BEFORE hostapd attempts to use
channel 149, fixing the boot-time AP failure loop.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: RTL8822CE driver caused kernel panic (watchdog hard LOCKUP) when
hostapd tried to use VHT 802.11ac with 80MHz channel width on channel 149.
Root cause: Driver/firmware instability with VHT capabilities on this chip.
Solution: Disable VHT, use HT40+ (802.11n) only.
- Removes ieee80211ac (VHT), ieee80211ax (802.11ax), and 80MHz channel width
- Keeps HT40+ with Short GI for reasonable performance
- Stable operation on channel 149 (5745 MHz)
This allows the 5GHz AP to start and beacon without lockup on R5C hardware.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: R5C spontaneously rebooted due to hardware watchdog timeout
Cause 1: van-gps-owntracks in infinite restart loop (MQTT connect failed)
Cause 2: mosquitto only listening on localhost, so clients couldn't connect
Solution:
- Add restart limits to van-gps-owntracks and van-li3-battery services
(max 3 restarts per 5 minutes prevents infinite restart loops)
- Configure mosquitto to listen on all interfaces (0.0.0.0:1883)
- Deploy mosquitto listener config via deploy.sh
- Restart mosquitto during deploy to apply config changes
This prevents the system from hitting the 11-second hardware watchdog timeout
when services crash and systemd auto-restarts them indefinitely.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The system dnsmasq.service from the Debian dnsmasq package conflicts with
van-ap-dnsmasq.service on port 53 (DNS/DHCP). Explicitly disable the system
service during deploy so only van-ap-dnsmasq (bound to br0 for AP DHCP) runs.
Fixes DHCP failures where clients connect to the AP but don't get IP addresses
because port 53 is already in use.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Check for required packages (hostapd, iw, nftables, dnsmasq, systemd-resolved)
at deploy start and fail if any are missing. Also warn about optional packages
used by specific components (rsync, mosquitto, gpsd, python3-paho-mqtt, etc.).
Missing required packages halt deployment with clear error message. Optional
packages generate warnings that are captured in deploy-warnings.json for the
router-status MQTT dashboard.
This prevents silent failures when the R5C or other hardware doesn't have
expected dependencies installed.
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>
Cockpit's login was unreliable (Firefox rejected sometimes, Android failed
outright with a TLS handshake error) and it was a resource hog on this Pi.
van-router-mqtt publishes the same AP/client/WAN/Starlink/modem status and
accepts the same control actions (AP/modem restart, WAN connect/disconnect,
prefer) via MQTT with HA discovery, using the local Mosquitto broker already
running here. It republishes van-failover/van-thermal's own state.json files
verbatim rather than modifying either daemon (van-thermal is deliberately
stdlib-only; van-failover's control loop wasn't worth an added dependency).
Adds a Lovelace dashboard (ha/dashboards/van-router.yaml) consuming those
entities. Cockpit's plugin is left deployed for now, not yet retired.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S2tpeaiHUriQbbnQ4SCbkf
Commands reverse-engineered from Bluetooth HCI snoop captures (adb bugreport)
of the official Carefree Connects (BT12) Android app, confirmed across three
independent captures including two isolated single-action live tests:
extend/retract (feature 0x05, values 0x01/0x02 -- the device toggles motor
state internally, there's no separate stop byte) and light on/off (feature
0x1a, values 0x19/0x01). Both live under GATT characteristic 02060002 on
service 02060001-50e1-405f-bab0-6bb582b4d96e.
Connects on demand per command (mirrors the app's own connect/act/disconnect
pattern) rather than holding a persistent connection like li3_battery, since
this device doesn't stream telemetry. Cover/light state is assumed/optimistic
-- the notify channel (02060003) isn't decoded yet, so a diagnostic sensor
just surfaces raw undecoded replies to build up data for that follow-on work.
Verified end-to-end against the real device: light on/off and awning
extend both worked through Home Assistant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The li3 BMS has a persistently marginal BLE link from any single fixed
vantage point on this Pi (onboard adapter, a USB dongle that turned out to
be BR/EDR-only, and the Athom ESPHome BT proxy even after moving it closer).
Move capture into HA proper so bluetooth.async_ble_device_from_address can
pick whichever known source currently has the device, instead of hardcoding
one. Protocol parsing ported verbatim from li3/van-li3-battery.
van-li3-battery is disabled on the Pi; its MQTT discovery entities were
cleared.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both sync-sd-backup.sh and sync-usb-backup.sh used set -e, so rsync
returning exit 24 (partial transfer due to vanished source files --
expected on a live root, e.g. a container's shm socket disappearing
mid-sync) aborted the script before it printed its own success message,
even though the actual file transfer completed fully. Only exit 24 is
now tolerated; any other rsync failure still aborts as before.
Found running sync-sd-backup.sh today: it transferred all 919k files
correctly but exited non-zero and skipped its completion line.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJfEELeh3ercpRBp8yYrYS
The in-kernel rtw89_8852bu on this Ubuntu kernel base predates mainline's
USB2->3 auto-switch for this chip, permanently capping the AP dongle at
USB2/480M. morrownr/rtw89 (dkms) has that switch. ap/rtw89.conf now
blacklists the in-kernel rtw89 modules and tunes the replacement
(disable_ps_mode + switch_usb_mode); ap/install-rtw89-driver.sh builds
and installs it, pinned to a specific upstream commit, kept separate
from deploy.sh since a dkms rebuild is too slow to run on every deploy.
Verified live: negotiates USB3/5000M on a dedicated USB3 controller
(480M on a USB2-only one, as expected), AP recovered via hostapd's
Restart=always + van-ap-watchdog with no manual intervention. Hit and
documented one real gotcha along the way: in-kernel rtw89_core refused
to unload while its own dependents (rtw89_8852b, rtw89_8852b_common)
were still loaded, which blocked the new module with a duplicate-symbol
error until all in-kernel modules were removed first.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJfEELeh3ercpRBp8yYrYS
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>
