memory: initial import (transferred from wayback) + hub-move and cockpit-EMFILE updates
Snapshot of the Pi 'wan' Claude memory: wayback van-router build notes, ZT DNS, HA VM, LAN port, and the Pi port memory updated for the 2026-07-06 USB hub move (AP live on the Pi) and the cockpit-bridge fd-limit fix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Andreas Wrede
Claude Fable 5
@@ -0,0 +1,18 @@
|
||||
# Memory Index
|
||||
|
||||
> Transferred 2026-07-06 from the Claude on wayback (which built the van router, the
|
||||
> Pi port, and everything below). **You run locally on the Pi 4 "wan"** — the machine
|
||||
> [Pi 4 'wan' port](pi-wan-port.md) describes; its "SSH andreas@192.168.6.128" access
|
||||
> notes are other machines' view of YOU. Your ~/vanlink (branch `wan`) is this host's
|
||||
> source of truth. **wayback is now the remote** (the notes' original perspective):
|
||||
> reach it at wayback.wrede.pvt / 192.168.10.251 (eth) / .27 (wifi) / 192.168.196.22
|
||||
> (ZT). The USB hub moved here 2026-07-06: **this Pi now runs the live VanLink AP**
|
||||
> (both bands beaconing; Starlink adapter still absent). wayback still hosts the HA VM
|
||||
> — see open items in [Pi 4 'wan' port](pi-wan-port.md).
|
||||
|
||||
- [wayback campervan AP](wayback-campervan-ap.md) — the whole build: dual-band hostapd (5GHz 80MHz/HE + 2.4GHz ch6 on separate rtw88 dongle/instance) + dnsmasq + nftables NAT, NM owns WAN, multi-WAN failover daemon, Cockpit "Van Router" plugin. Hard-won gotchas (rtw89/rtw88 power-save, USB-hub load hang, reapply→carrier flap, EEE, curl `if!`). Source of truth: ~/vanlink/.
|
||||
- [ZeroTier managed DNS](zerotier-managed-dns.md) — wrede.pvt resolves over ZT via zerotier-systemd-manager + systemd-networkd (native ZT setDns is a no-op on Linux).
|
||||
- [wayback fan max = EC latch](wayback-fan-max-ec-latch.md) — fan stuck at max was a latched EC failsafe; fixed by full power-drain reset (warm reboot won't clear it).
|
||||
- [Home Assistant VM](homeassistant-vm.md) — HAOS runs as libvirt KVM VM `ha_van` bridged onto br0 at 10.42.0.50:8123 (name `homeassistant`; legacy 10.42.0.1:8123 DNAT kept); documented in vanlink repo under ha/. The old NAT+iptables-hook setup rotted on libvirtd restarts.
|
||||
- [LAN port + asymmetric mgmt access](lan-port-and-asymmetric-mgmt-access.md) — enx00e04c331140 bridged into br0 as a wired LAN port; never SSH to 10.42.0.1 from the upstream LAN (asymmetric path, drops at ~125s) — use wayback.lo/.zt.wrede.pvt.
|
||||
- [Pi 4 'wan' port](pi-wan-port.md) — full vanlink stack on the Pi (192.168.6.128, branch `wan` of its own clone), live since the hub moved 2026-07-06. Watch: netplan-wpa unit fights NM; bcm2835 watchdog max 15s; HA VM + ZT route still need a plan; cockpit-bridge EMFILE fixed (batched spawns + LimitNOFILE drop-in).
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
name: homeassistant-vm
|
||||
description: "Home Assistant OS runs as a libvirt/KVM VM (ha_van) bridged onto br0 at 10.42.0.50; how it's networked and reached."
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 2a8455f6-a504-4683-b972-73a2930ce600
|
||||
---
|
||||
|
||||
Home Assistant OS runs as a KVM VM on wayback, installed 2026-06-29 per the official
|
||||
linux/virt-install docs. **Re-plumbed 2026-07-06: NIC bridged onto `br0`** (commit `a7819ed`
|
||||
in [[wayback-campervan-ap]] `~/vanlink`, dir `ha/`, README §3 "Home Assistant VM").
|
||||
|
||||
- **Domain:** `ha_van` (libvirt/qemu), autostart enabled. 4 GB RAM, 2 vCPU, 32 GB disk.
|
||||
Disk: `/var/lib/libvirt/images/haos_ova-17.3.qcow2` (scsi/virtio-scsi, UEFI non-secureboot
|
||||
OVMF `/usr/share/OVMF/OVMF_CODE_4M.fd`). HAOS **17.3** — 18.0 was pulled from stable (bug #4811).
|
||||
Domain XML reference copy: `~/vanlink/ha/ha_van.xml`.
|
||||
- **Networking = bridged into `br0`** (`<interface type='bridge'>`, model **virtio** — was e1000,
|
||||
HAOS took the change without complaint). MAC `52:54:00:ad:0a:01`, pinned lease **10.42.0.50**
|
||||
+ DNS name `homeassistant` via `dhcp-host` in van-ap dnsmasq (`~/vanlink/ap/van-ap-dnsmasq.conf`).
|
||||
First-class LAN device: mDNS/SSDP discovery works, HA sees real client IPs.
|
||||
- **URLs:** `http://10.42.0.50:8123`, `http://homeassistant:8123`, `homeassistant.local` (mDNS),
|
||||
and the legacy `http://10.42.0.1:8123` — kept working via nft DNAT in `ap/nftables.conf` plus a
|
||||
hairpin masquerade for same-subnet clients (VM would otherwise reply directly on br0 from .50
|
||||
and the client, expecting .1, drops it). ZT clients: all of the above work — the ZT network
|
||||
(nwid d3ecf5726d041b2a) publishes a managed route `10.42.0.0/24 -> 192.168.196.22`
|
||||
(controller-side); VM replies route back through its gateway 10.42.0.1, symmetric, no masquerade.
|
||||
- **Why bridged (history):** it originally sat on libvirt's `default` NAT net (192.168.122.50)
|
||||
with a `/etc/libvirt/hooks/network` hook inserting FORWARD ACCEPTs above libvirt's
|
||||
`LIBVIRT_FWI` REJECT. **That rotted**: a libvirtd restart re-inserts libvirt's chain jumps at
|
||||
the top of FORWARD *without firing the network hook*, pushing the ACCEPTs below the REJECT —
|
||||
found dead 2026-07-06 (0 pkts on both ACCEPTs). Bridging removed the failure mode. The hook,
|
||||
the 192.168.122.50 reservation, and the iptables rules are deleted.
|
||||
- Cockpit "Virtual Machines" page requires `cockpit-machines` (installed). `br_netfilter` is not
|
||||
loaded, so client↔VM L2 traffic on br0 never touches iptables/nftables.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: lan-port-and-asymmetric-mgmt-access
|
||||
description: Wired LAN port bridged into br0; never SSH to 10.42.0.1 from the upstream LAN (asymmetric path drops at ~125s)
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: reference
|
||||
originSessionId: 319a7835-e94a-4021-a56f-dc5714162cf0
|
||||
---
|
||||
|
||||
Two facts about reaching/managing wayback's LAN side.
|
||||
|
||||
**Wired LAN port.** `enx00e04c331140` is now a LAN port, bridged with the AP wlan into
|
||||
`br0` (gateway 10.42.0.1/24, dnsmasq DHCP .10–.254). The 10.42.0.1 IP, NAT (`oifname != br0`),
|
||||
and dnsmasq all moved off the wlan name onto `br0`. Files in `~/vanlink/ap/`:
|
||||
`20-van-br0.netdev`, `21-van-br0.network`, `22-van-lan.network`; hostapd has `bridge=br0`
|
||||
(hostapd, not networkd, enslaves the wlan — a station-mode wlan can't be bridged until AP mode).
|
||||
Starlink (`enxd8ec5eeb3512`) is untouched and stays the failover WAN.
|
||||
|
||||
**Don't SSH to 10.42.0.1 from a host on the 192.168.10.0/24 LAN.** It's the LAN-side gateway IP;
|
||||
a request from the upstream LAN comes *in* via ZeroTier (the only route to 10.42.0.0/24) but the
|
||||
reply goes *out* `wlp1s0` directly (on-link metric 100 beats the ZT route metric 5000) — asymmetric.
|
||||
The SSH session then dies at ~125s because the ZeroTier UDP transport's return-leg conntrack entry
|
||||
(`nf_conntrack_udp_timeout_stream = 120`) expires with no return traffic. Confirmed, not worth fixing
|
||||
(the connmark policy-routing fix was declined). Instead use DNS that matches location:
|
||||
`wayback.lo.wrede.pvt` when local (direct LAN, symmetric, solid) or `wayback.zt.wrede.pvt` when
|
||||
remote. See [[zerotier-managed-dns]] and [[wayback-campervan-ap]].
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: pi-wan-port
|
||||
description: "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."
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 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).
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: wayback-campervan-ap
|
||||
description: "wayback campervan router/AP — hand-rolled hostapd (RTL8852BU, 80MHz/HE) + dnsmasq + nftables; NM owns WAN; eventual Starlink+4G multi-WAN"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 0f399db0-9a91-4f55-b102-70875f05be7a
|
||||
---
|
||||
|
||||
Goal: turn wayback (Asus UX391U laptop, Ubuntu 24.04) into a campervan hub/router/AP. Eventual WAN = Starlink (ethernet) + 4G/5G modem with failover; LAN = wifi AP for clients. See [[wayback-fan-max-ec-latch]].
|
||||
|
||||
**SOURCE OF TRUTH: `~/vanlink/` on wayback** (2026-06-28). Consolidated working dir, Claude Code now installed ON wayback so future van-router dev happens there. Contains README.md (full architecture + gotchas + ops), `deploy.sh` (copies files→system locations, idempotent), and copies of every config/script grouped: `ap/` `failover/` `dns/` `cockpit/vanrouter/`. Edit there, `sudo ./deploy.sh`. This memory is the why/history; the README is the operational reference.
|
||||
|
||||
**Architecture (2026-06-28): hand-rolled hostapd + dnsmasq + nftables, NM owns WAN.** Decided against NM-hotspot (capped at HT20/20MHz) and against RaspAP (RPi-OS/dhcpcd tool; bare-metal installer would enable dhcpcd → fight NM, and disable systemd-resolved → unsafe on this x86/Ubuntu/NM box).
|
||||
|
||||
Radios:
|
||||
- **phy1 = Realtek RTL8852BU** (`0bda:b832`, driver `rtw89_8852bu`, iface `wlxc83a35a4ee55`) = AP radio. Confirmed empirically: AP mode + **VHT80 + HE (WiFi-6)** at 80MHz works.
|
||||
- **phy0 = Intel 8265** (`wlp1s0`) = mgmt/uplink, assoc home SSID `Wapana` (192.168.10.27).
|
||||
- **2.4GHz AP added 2026-07-06 (commit `e652b0f`): Linksys WUSB6300v2** (`13b1:0045`, RTL8822BU, driver `rtw88_8822bu`, iface `wlxd8ec5e2faa8c`). Same SSID/PSK, ch6 HT20, bridged into br0. **Own hostapd instance** (`hostapd-2g.service` + `van-ap-watchdog-2g`) so one radio's USB wedge can't kill the other; `van-ap-watchdog` now takes conf+unit args. `/etc/modprobe.d/rtw88.conf`: `disable_lps_deep=Y` (PS gotcha analog) + `switch_usb_mode=N` (blocks driver's USB2→3 self-upgrade only — the dongle sits in a USB3 port and still enumerates SuperSpeed; move to a USB2 port if 2.4GHz range/interference disappoints). Shares Bus 002 with an RTL8153 — watch for the hub-contention signature. Cockpit vanrouter plugin shows both bands with per-band Restart (`const APS` list in vanrouter.js, commit `db16964`).
|
||||
|
||||
Management/recovery paths (3): ethernet `enx00e04c3600ab` **192.168.10.235** (USB RTL8152; now PRIMARY default route metric100 — previews Starlink-on-eth), wifi `wlp1s0` .27 (metric600), ZeroTier `ztuga7c2kh` 192.168.196.22.
|
||||
|
||||
Deployed config (all enabled at boot):
|
||||
- **hostapd** `/etc/hostapd/hostapd.conf`: SSID `VanLink`, ch149 VHT80/HE, WPA2-PSK (user changed it 2026-06-28; valid = 8-63 chars), `country_code=CA`. `/etc/default/hostapd` DAEMON_CONF set. (was masked during testing — now unmasked/enabled.)
|
||||
- **rtw89 power-save MUST be disabled** for AP stability: `/etc/modprobe.d/rtw89.conf` = `options rtw89_core disable_ps_mode=Y`. ROOT CAUSE of "SSID disappears after a few min": when the last client idles out (hostapd 5-min inactivity timer), rtw89 low-power mode sleeps the radio and STOPS beaconing until restart. To apply live you must unload the WHOLE stack so rtw89_core reloads (`modprobe -r rtw89_8852bu rtw89_usb rtw89_8852b rtw89_8852b_common rtw89_core` then `modprobe rtw89_8852bu`; -r of just the leaf does NOT cascade to core). Verify `cat /sys/module/rtw89_core/parameters/disable_ps_mode` = Y.
|
||||
- GOTCHA: Ubuntu's hostapd does NOT support `noscan` (rejects "unknown configuration item 'noscan'" → service fails). Don't add it. Restarts occasionally log stuck at HT_SCAN but still beacon — trust `iw dev <ap> info` (ssid+channel+width present = beaconing), not the journal ENABLED line.
|
||||
- AP iface **unmanaged by NM** via `/etc/NetworkManager/conf.d/van-ap-unmanaged.conf`; static IP 10.42.0.1/24 via **systemd-networkd** `/etc/systemd/network/10-van-ap.network` (ConfigureWithoutCarrier=yes).
|
||||
- **dnsmasq** dedicated instance (binary from dnsmasq-base, NOT the distro service): config `/etc/van-ap/dnsmasq.conf` (interface=AP, bind-dynamic → no clash with systemd-resolved on 127.0.0.53), unit `van-ap-dnsmasq.service`. DHCP 10.42.0.10-254/12h, gw+dns 10.42.0.1.
|
||||
- **nftables** `/etc/nftables.conf`: own table `van_router_nat` (create+delete idiom, no global flush) masquerading `10.42.0.0/24 oifname != AP` → covers any WAN. `ip_forward=1` persisted in `/etc/sysctl.d/99-van-router.conf`.
|
||||
- **regdomain.service** (oneshot `iw reg set CA`, Before=NetworkManager) — needed: country 00 only allows 5GHz ch36/48; CA unlocks ch149-161 @30dBm no-DFS.
|
||||
- Cockpit on :9090 still installed (system/WAN monitoring; canNOT edit wifi — cockpit-networkmanager has no wifi UI).
|
||||
|
||||
To change AP: edit `/etc/hostapd/hostapd.conf` + `systemctl restart hostapd`. DHCP: `/etc/van-ap/dnsmasq.conf` + restart `van-ap-dnsmasq`.
|
||||
|
||||
Reboot-persistence VERIFIED (2026-06-28): after `systemctl reboot` all 4 services auto-started, regdomain CA applied, disable_ps_mode=Y from boot, VanLink beaconing 80MHz, ethernet .235 recovery path back. (Lesson: avoid hot-reloading rtw89_8852bu; reboot to apply module options.)
|
||||
|
||||
**RESOLVED — load-hang was USB hub contention.** Symptom: Android Speedtest (good numbers, then dropped), SSID invisible while hostapd still "active". Fatal dmesg signature = `c2h reg timeout` + `Polling beacon packet empty fail` (chip↔host USB comms hang → beacon TX stops); recovers via `systemctl restart hostapd`. Root cause: the dongle was on a shared USB-2 hub (`1-1.4`) with the r8152 ethernet + a camera; under load the shared bus starved chip comms. FIX (2026-06-28): moved Realtek to its own root USB-C port (`1-3`). After move: 3 Speedtests completed, ZERO c2h/beacon-fail errors, 2 clients at 80MHz HE (WiFi-6) >1Gbit/s PHY, tx-failed ~0. The lone post-move `timed out to flush queues` is BENIGN (doesn't drop AP); the c2h+beacon-fail combo is the fatal one.
|
||||
Caveats: (1) the 8852BU is **USB-2.0-native** — enumerates 480M even on a USB-C/USB-3 port (USB3 can't speed a USB2 device); ~280Mbps real USB ceiling = fine for Starlink/4G van WAN but that's the aggregate cap. (2) In the van build keep the AP dongle and the WAN ethernet on **separate USB controllers** — don't re-share a hub or the c2h hang returns. (3) Interface name is MAC-based (wlxc83a35a4ee55), survives port moves; all configs reference the name. Unused fallback if it ever regresses: pivot AP to Intel 8265 (PCIe, WiFi5/ac 80MHz).
|
||||
Note: iw sometimes reports control channel as 153 (not the configured 149) within the same 149-161/80MHz block — cosmetic, clients connect fine.
|
||||
|
||||
Pending / next steps:
|
||||
- **Idle-survival still being confirmed**: original symptom was beacon dropping ~5min after last client idled out (hostapd 5-min inactivity deauth). Watching across an idle cycle post-fix. Strongest real test = connect a device, use it, let it idle past 5 min, confirm SSID stays visible.
|
||||
- **Verify**: client association → DHCP + internet (basic assoc seen; full internet path not yet end-to-end tested).
|
||||
- **Multi-WAN failover BUILT + TESTED (2026-06-28).** Daemon `/usr/local/sbin/van-failover` (Python), config `/etc/van-failover/config.json`, unit `van-failover.service` (Restart=always, enabled). 3 WANs, priority = **WiFi(wlp1s0)=100 → Starlink/eth(enxd8ec5eeb3512)=200 → 4G(Koodo gsm)=300** (user chose WiFi-first to save Starlink; 4G auto last-resort). How it works: probes each WAN's real internet every 4s via HTTP-204 check (catches "link up no internet" + captive portals), demotes a failed WAN by raising its NM route-metric (+10000) so kernel routes via next-best healthy WAN; auto fail-back with hysteresis (3 fail→down, 2 ok→up). Writes `/run/van-failover/state.json` (0644) → Cockpit "WAN Failover" card reads it. NAT (nftables oifname != AP) follows automatically; nothing else needed. Tested with an nft block on wlp1s0:80 → failed over to Starlink in ~30s, failed back in ~20s.
|
||||
- **GOTCHA: per-WAN probing needs `curl --interface if!<dev>`** (explicit SO_BINDTODEVICE) — plain `--interface <name>` binds source IP but still routes via the default WAN, so all probes test the same path. rp_filter is already 2 (loose) which is required. Probe all (WAN×url) pairs CONCURRENTLY else a dead WAN takes N×timeout serially (was why first failover test looked broken). `ping -I` to test eth is unreliable here (ICMP lossy on the gateway) — use the curl-204 check.
|
||||
- Absent WANs (modem unplugged → Koodo has no device): daemon skips probing, just sets the profile's base metric so it lands right when it connects. ModemManager active + `Koodo` gsm profile autoconnect=yes already present; lights up when USB modem arrives.
|
||||
- **CRITICAL fix (r8152 USB-ethernet flapping)**: the daemon must change route-metrics via `ip route` (del/add default at new metric), NOT `nmcli device reapply` — **reapply RESETS the r8152 carrier** (verified: reapply=2 carrier events, ip-route=0), causing ~10s ping drops + a feedback loop (transient probe fail → reapply → carrier reset → more fails). Daemon keeps the NM profile metric in sync (`nmcli con mod`, no reapply) so NM re-assertions don't drift. Also: **disable EEE** on the eth adapter or its idle (backup, no-traffic) link parks and probes fail — done via NM dispatcher `/etc/NetworkManager/dispatcher.d/50-disable-eee` (runs `ethtool --set-eee <if> eee off` on up; ethtool setting doesn't persist otherwise). Also: **arp_ignore=1 / arp_announce=2** (`/etc/sysctl.d/99-van-arp.conf`) to stop ARP flux when two WANs share a subnet (a home-LAN test artifact; in the van Starlink+wifi are on different subnets). After all three: eth stable, failover/failback clean, 0 carrier resets even when eth becomes active.
|
||||
- To tune: edit config.json (probe_interval/timeout, thresholds, probe_urls, wans list) + `systemctl restart van-failover`. WAN list keys eth/wifi by `device`, cellular by `connection` name.
|
||||
- **Cockpit plugin BUILT (basic v1, 2026-06-28)**: `/usr/share/cockpit/vanrouter/` (manifest.json menu "Van Router" + index.html + vanrouter.css + vanrouter.js). Pure static + cockpit.js: read-only status via `cockpit.spawn` as logged-in user (iw info/station dump, nmcli device status, `ip -j route/addr`, systemctl is-active); mutating actions use `{superuser:"require"}` (polkit). Features: AP panel (hostapd state, SSID/ch/width, client list) + Restart AP; WAN panel (per NM ethernet/wifi device: state/IP/route-metric, ★=active default) with Up/Down (`nmcli device connect/disconnect`) and Prefer (sets chosen route-metric=50, others=200, `nmcli device reapply`). AP iface name hardcoded as const AP. Confirmed discovered via `cockpit-bridge --packages`. To see it: reload Cockpit browser / re-login; enable Administrative access for the buttons. **Now also has a "WAN Failover" card** reading `/run/van-failover/state.json` (active egress + per-WAN priority/device/up-down/metric). Source only on host + session scratchpad (not in a repo).
|
||||
- **Evaluated & REJECTED `apsetup-cockpit`** (github cyberorg/apsetup-cockpit, 2026-06-28): NM-hotspot-based AP tool (uses an NM dispatcher `90apnmdispatcher` + its own dnsmasq + NAT; needs `DNSStubListener=no`). Doesn't fit: (1) NM-created AP on rtw89 = HT20/20MHz, throws away our 80MHz/HE; (2) it owns the AP (own NM conn/dnsmasq/NAT) → collides with our hand-rolled hostapd+van-ap-dnsmasq+nftables + AP-iface-unmanaged; (3) disables resolved stub host-wide (we kept resolved via bind-dynamic). If a web AP-config form is wanted, ADD an SSID/channel/PSK card to our own vanrouter plugin editing /etc/hostapd/hostapd.conf + restart hostapd — keeps 80MHz, no conflict.
|
||||
- **Mgmt ethernet changed (2026-06-28)**: now `enxd8ec5eeb3512` @ 192.168.10.251 (metric100, active default); old `enx00e04c3600ab` @ .235 now `unavailable` (swapped/unplugged during USB reorg). Cockpit now at https://192.168.10.251:9090. AP NAT (oifname != AP) follows it automatically. Stale NM profile for the .235 adapter still present (shows "unavailable" in plugin).
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: wayback-fan-max-ec-latch
|
||||
description: "wayback (Asus UX391U) fan stuck at max = latched EC failsafe; fixed by full power-drain EC reset, not warm reboot"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 0f399db0-9a91-4f55-b102-70875f05be7a
|
||||
---
|
||||
|
||||
wayback = Asus ZenBook UX391UA (BIOS UX391UA.307, 2020; latest), Ubuntu 24.04, ZFS on zabbly kernel.
|
||||
|
||||
On 2026-06-28 the fan ran continuously at max with cool CPU (~50°C idle). **Root cause: the Asus EC latched into its fan failsafe, commanding 100% unconditionally.** EC temperature *sensing* was fine (EC byte 0xA0 tracked 43°C→96°C under load); only the fan *output* was stuck.
|
||||
|
||||
**Key facts about fan control on this machine:**
|
||||
- The OS has NO fan-control authority: no ACPI fan object (`PNP0C0B` absent, no fan `cooling_device`), no writable `pwm1` (only `pwm1_enable` on hwmon `asus`/asus-nb-wmi), `asus_wmi` fan-curve unsupported (`fan_curve_get_factory_default … failed: -19`), DPTF `INT3400` is `mode=disabled` (firmware-controlled). So this is never a Linux/driver issue — it's pure EC.
|
||||
- `sensors` `asus-isa-0000 cpu_fan: 25500 RPM` is a meaningless `0xFF×100` sentinel from the unsupported asus read path. Ignore it as a diagnostic.
|
||||
|
||||
**Fix:** full power-drain EC reset — shutdown, unplug charger AND all USB-C power, hold power button ~40s, reboot. A warm reboot does NOT clear it (EC stays powered through it). This resolved it; fan quiet at idle afterward.
|
||||
|
||||
**If it recurs:** same power-drain reset. If it returns *immediately* after a clean EC reset (loud at idle, cool temps) → hardware fault (failing fan or open thermistor), not a latch.
|
||||
|
||||
Quick EC inspection: `sudo modprobe ec_sys` then `sudo xxd /sys/kernel/debug/ec/ec0/io` (byte 0xA0 = CPU temp °C). `rmmod ec_sys` when done.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: zerotier-managed-dns
|
||||
description: "How ZeroTier managed DNS (wrede.pvt over ZT) is wired on Linux hosts — zerotier-systemd-manager + networkd, NOT native ZT"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: reference
|
||||
originSessionId: 0f399db0-9a91-4f55-b102-70875f05be7a
|
||||
---
|
||||
|
||||
ZeroTier network `d3ecf5726d041b2a` ("suspicious_house", iface `ztuga7c2kh`, 192.168.196.0/24) pushes managed DNS: domain `wrede.pvt`, servers `192.168.196.115` + `192.168.10.5`. Goal: when a host is AWAY from the home LAN, `*.wrede.pvt` resolves over ZeroTier.
|
||||
|
||||
**GOTCHA: ZeroTier's native DNS push is a no-op on Linux.** `journalctl -u zerotier-one` shows `WARNING: ignoring call to LinuxEthernetTap::setDns on Linux. This is not implemented yet` (ZeroTierOne#2492). So `zerotier-cli set <nwid> allowDNS=1` alone does NOTHING for resolution on Linux — it's only the prerequisite that lets the pushed DNS appear in network config.
|
||||
|
||||
**Actual mechanism = `zerotier-systemd-manager`** (Go binary, hand-installed — NOT in the zerotier apt repo; v0.4.0 at /usr/bin/zerotier-systemd-manager). It reads ZT networks and generates `/etc/systemd/network/99-<ztdev>.network` with `DNS=` + `Domains=~wrede.pvt ~<reverse zones>`, then reloads systemd-networkd which applies it to systemd-resolved. Ships a `.service` (oneshot) + `.timer` (regenerates every 1 min) in /usr/lib/systemd/system/. Requires systemd-networkd enabled+active.
|
||||
|
||||
Setup recipe (done on wertvoll, replicated on wayback 2026-06-28):
|
||||
1. `zerotier-cli set d3ecf5726d041b2a allowDNS=1` (writes networks.d/<nwid>.local.conf).
|
||||
2. Install zerotier-systemd-manager (copy binary + 2 unit files; both hosts amd64). `systemctl enable --now zerotier-systemd-manager.timer`.
|
||||
3. Ensure systemd-networkd enabled+active.
|
||||
4. Optional bare-hostname search: drop-in `99-<ztdev>.network.d/search.conf` making `wrede.pvt` a SEARCH domain (no `~`).
|
||||
Verify: `resolvectl status <ztdev>` → Current Scopes: DNS, the 2 servers, `DNS Domain: wrede.pvt ~rev…`. On-home-LAN it still prefers the LAN link for wrede.pvt (both have the domain) — that's correct; ZT is the path when off-LAN.
|
||||
|
||||
wayback-specific: see [[wayback-campervan-ap]]. wayback's `search.conf` uses `Domains=` (reset) then `Domains=wrede.pvt ~196.168.192.in-addr.arpa ~c.e.3.d.d.f.ip6.arpa` because wertvoll's plain `Domains=wrede.pvt` drop-in did NOT merge on wayback (same systemd 255 — cause unknown); the reset form yields the identical resolved result. An empty `/etc/NetworkManager/conf.d/10-globally-managed-devices.conf` was briefly added to match wertvoll, then REMOVED — confirmed not needed (removing it left ZT DNS fully working, since networkd not NM drives it). wertvoll still has it but it's incidental.
|
||||
Reference in New Issue
Block a user