From 708379732e4462406ea38988b9ec9f78aa2ff21d Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Tue, 16 Jun 2026 13:43:23 -0700 Subject: [PATCH] sync: auto-sync from HOWARD-HOME at 2026-06-16 13:43:14 Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-16 13:43:14 --- ...026-06-15-howard-cascades-wifi-rf-audit.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md b/clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md index 00c6656..c6c9a5e 100644 --- a/clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md +++ b/clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md @@ -575,3 +575,40 @@ when the VPN started flapping (don't tie home gateway IP to an unstable tunnel). VPN FLAP: OpenVPN Connect DCO instability (DCO adapter Disconnected, TAP up, 4 OpenVPNConnect procs) - the same DCO/TAP issue seen earlier. Fix: disable DCO in OpenVPN Connect (force TAP datapath) OR switch to community OpenVPN GUI; also check duplicate-CN (cert connected from 2 devices = connect/disconnect loop). + +## Update: 13:42 PT (2026-06-16) — pfSense compat layer: started, backed out, aligned to Mike's design + +Picked up "start the pfSense compat layer." Began a REST-API-backed `pfsense-audit.sh` **sibling** +scaffold + a `references/pfsense-driver.md` design doc. On re-reading the repo, corrected course: + +- **What Mike actually built vs proposed.** `gw-control.sh` (commit `eb87710`) is **UniFi** gateway + control — it calls `/proxy/network/api/...` (the UniFi controller REST), validated on Grabb's + **USG-3P**. It does NOT touch pfSense. Commit `6998719` is a **roadmap entry** — ROADMAP §E + "pfSense gateway compatibility layer," a design with explicit **OPEN DECISIONS**, not built code. + So Mike *designed* the pfSense layer (with questions to resolve first); he did not build it. +- **I had pre-empted his open decisions.** §E leaves two open: (1) backend = REST API package vs + stock SSH `easyrule`/`pfSsh.php`; (2) where the abstraction lives = dispatch **inside** + `gw-audit.sh`/`gw-control.sh` (keyed on `num_gw=0`) vs sibling `pf-*` scripts — Mike leans "inside." + My scaffold unilaterally picked REST + a sibling script (the opposite structure). +- **Backed it out.** Removed `pfsense-audit.sh` + `pfsense-driver.md` (never committed/pushed) rather + than fork Mike's design. Released coord lock `a34360aa`. Messaged Mike (GURU-5070, id `e402e783`) + with the two open decisions and my lean. +- **Howard's decision:** "let us try what mike wanted and go that way unless we run into a real + roadblock we can't work past." → **REST API package backend, dispatched INSIDE + `gw-audit.sh`/`gw-control.sh`** (Mike's option 1 + his structural lean). Build to that next. + +**Net for this update:** no code shipped; design alignment + coordination only. The WiFi/RF work +(Floor-4 pilot applied + held, Phase-C disables held, steering/min-rate/channel-plan dry-run-validated) +is unchanged from earlier in this log. + +### Next steps (pfSense layer, per Howard + Mike) +1. Per-site setup helper: install `pfSense-pkg-RESTAPI` + create a read-only key + vault at + `clients//pfsense-api` (url+apikey). Cascades + ACG office have pfSense web creds vaulted + already (`clients/cascades-tucson/pfsense-firewall`, `infrastructure/pfsense-firewall`) — need the + API key added. +2. Add a pfSense backend **inside** `gw-audit.sh` (dispatch on `num_gw=0`): WAN/gateway status via + `/api/v2/status/gateways`, system, DHCP pool pressure. Then `gw-control.sh` verbs (pf-list/disable/ + enable/set-ports, fw-disable/enable, block-ips) onto `firewall/nat/port_forward` + `firewall/rule` + + `easyrule`-equivalent. +3. Live validation pending a reachable pfSense (stable site VPN; mind the home-LAN .0.x shadow that + currently masks Cascades pfSense from Howard-Home). Coordinate the build with Mike (his §E).