sync: auto-sync from HOWARD-HOME at 2026-06-15 22:06:13

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-15 22:06:13

.claude/skills/unifi-wifi/scripts/watch-ap.sh

@@ -37,7 +37,8 @@ fi
 echo "[INFO] watching $AP every ${INT}s (Ctrl-C to stop). Needs Cascades VPN reach."
 # Run the sampling loop ON the AP so each tick is one round-trip; mca-dump for cu/clients, iw survey for busy%/noise.
 run_ssh "$U@$AP" "INT=$INT sh -s" <<'REMOTE' 2>&1 | grep -viE 'Warning: Permanently|pq.html'
-radios=$(iw dev 2>/dev/null | awk '/Interface/{print $2}' | grep -E 'wifi|ath' || echo "wifi0 wifi1 wifi2")
+# physical radios only — exclude virtual APs (wifi0ap0...) and mld-* (hyphen breaks ${VAR} expansion)
+radios=$(iw dev 2>/dev/null | awk '/Interface/{print $2}' | grep -E '^(wifi[0-9]+|ath[0-9]+)$' || echo "wifi0 wifi1 wifi2")
 prev=""
 while :; do
   ts=$(date +%H:%M:%S)

clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md

@@ -123,3 +123,54 @@ earlier read.
 - [ ] 6GHz steering plan; 5GHz 80->40MHz + non-DFS channel plan (resilience).
 - [ ] Coord msgs this update: RW-cred request 6b98282f (+todo cbb355ef); live-stats fix e8be889f.
 - [ ] pfSense `.ovpn` (Howard handling) — needed for per-AP watch-ap.sh live stream.
+
+---
+
+## Update: 22:05 PT — site VPN up (split-tunnel), direct-AP cross-validation, watch-ap.sh fixed
+
+Howard got the Cascades OpenVPN running. The pushed config is **full-tunnel** (pfSense
+`redirect-gateway`) which killed his local internet + Tailscale (and my tool calls, since they run
+on his machine). Fixed with a **split-tunnel client profile**:
+`C:\Users\Howard\Documents\ComputerGuru Connect v2\Files\cascades-splittunnel.ovpn` — copy of the
+working profile + `pull-filter ignore "redirect-gateway"`, `pull-filter ignore "dhcp-option DNS"`,
+`route 192.168.0.0 255.255.252.0`, and the VPN creds embedded inline (`<auth-user-pass>` =
+vault `clients/cascades-tucson/pfsense-openvpn-howard`, user `Howard`). After import+connect:
+internet + Tailscale + direct AP reach all work simultaneously.
+
+### Rescan + ground-truth verification (Howard: "test until sure there are no issues")
+- Controller rescan: **77/77 APs**, config identical to prior pull — no drift, scripts stable.
+- **Cross-validated controller data against AP ground truth** (direct SSH to APs, `mca-dump` +
+  `iw survey`) on TWO APs (132 @192.168.2.34, 335 @192.168.3.46): controller cu_total/clients
+  match the radios' own numbers within polling jitter (AP132 2.4: controller 81% / mca 87% / iw
+  survey 92% busy, -95dBm noise; AP335: 2.4 controller 81% vs mca 79%, 5GHz 10%=10% exact,
+  clients 2=2 exact). **Conclusion: the controller is accurate; the diagnosis stands on solid data.**
+- New concrete fact: U7-Pro 2.4 radios report `min_txpower 6 / max 23 dBm` → "Low" = 6 dBm
+  (aggressive cell shrink — good for the power-down plan).
+
+### watch-ap.sh fixed (2 bugs found by testing; validated live; Mike notified b0cf24a5)
+1. Hard `sshpass` dependency → failed on Windows (no sshpass). Added **SSH_ASKPASS fallback**
+   (temp askpass helper + `SSH_ASKPASS_REQUIRE=force`); uses sshpass if present. Fallback needs
+   `ssh` from PATH = MSYS ssh on Windows (system OpenSSH can't exec a shell askpass, CreateProcessW
+   err 193); Linux/macOS system ssh is fine.
+2. Radio list included virtual APs (`wifi0ap0..`) + `mld-wifi0` → duplicate lines AND
+   `sh: malformed ?: operator` (hyphen in `mld-wifi0` broke `${ACT_mld-wifi0:-0}`). Filter now
+   `grep -E '^(wifi[0-9]+|ath[0-9]+)$'`. Validated: clean 3-line/tick (wifi0 ch6 92%, wifi1 8%,
+   wifi2 0%).
+   - Minor (not fixed, interactive use is fine): script's `grep|head` block-buffers when piped
+     non-interactively; would need `stdbuf -oL` to be pipeable.
+
+### Issues found this round (none in the data; environment/VPN only)
+- **192.168.0.0/24 home-LAN overlap:** Howard's home LAN is 192.168.0.x, so Cascades devices on
+  192.168.0.x (pfSense `192.168.0.1`, cascadesDS `192.168.0.120`) are **shadowed/unreachable over
+  the VPN** from Howard-Home. APs on 192.168.2.x/3.x are unaffected. Use Tailscale for controller;
+  for pfSense/NAS over VPN would need a home renumber or a more specific route trick.
+- **OpenVPN Connect DCO↔TAP failover** intermittently drops the 192.168.2.x route mid-session
+  (caused two transient watch-ap timeouts). Community **OpenVPN GUI** is the more stable client if
+  it recurs.
+
+### State / next
+- live-stats.sh + watch-ap.sh both fixed + validated; controller data verified accurate.
+- NEXT (per Howard): one more clean retest pass, then build the **AP-to-AP RF-neighbor table**
+  (now feasible via direct AP `iw scan`/scan_radio_table) to unlock safe radio DISABLEs; then the
+  Floor-4 2.4 power-down pilot with live before/after validation.
+- Coord this update: watch-ap.sh fix b0cf24a5.