azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-16 19:29:08

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-16 19:29:08
This commit is contained in:
Howard Enos
2026-06-16 19:29:17 -07:00
parent e09ff5dc9b
commit 2b123679f9
2 changed files with 56 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -685,3 +685,39 @@ Scope for tonight: recommended = power-down-all + pilot ONE floor's disables, va
### Note: mesh data is from .claude/tmp/cascades-nbr.json (fresh tonight, gitignored) — regenerate via
neighbor-collect before execution if stale.
## Update: 19:28 PT (2026-06-16) — home LAN renumber fixes VPN shadow; pfSense ruled out as WiFi cause; SSH backend
### Home-LAN shadow RESOLVED (unblocked Cascades pfSense access)
Diagnosed why the Cascades VPN couldn't reach 192.168.0.x: Howard-Home was 192.168.0.0/24 with a UniFi
gateway at 192.168.0.1 (cert unifi.local — NOT pfSense), colliding with Cascades' own 192.168.0.0/24
(pfSense .0.1). OS prefers the directly-connected local /24, so 192.168.0.x never crossed the tunnel
(APs on 192.168.2.x/3.x worked). A /32 route can't fix it (.0.1 was Howard's own gateway). **Howard
renumbered Howard-Home to 10.137.42.0/24** (gw 10.137.42.1). Verified: ping 192.168.0.1 now replies over
the tunnel (TTL 64, ~15ms); cert = CN=pfSense-685f277aa6886 / "Netgate pfSense Plus" (the REAL Cascades
pfSense); NAS .120 reachable; controller-side (172.16.3.29) + AP reach (192.168.2.79) intact. Memory:
[[howard-home-lan-shadow]] updated to RESOLVED.
### pfSense investigated — NOT a WiFi factor (gateway ruled out)
SSH into Cascades pfSense (admin, shell works directly — no menu gotcha; pfSense Plus 25.07-RELEASE).
Findings: DHCP NOT exhausted (0 "no free leases"; WiFi/AP pool 192.168.0.0/22 range .2.2-.3.254 cap ~507
at 270 active ~53%; 199 subnets total, mostly per-unit /28s; active backend ISC, Kea dormant); unbound DNS
up; dual-WAN (WAN1 184.191.143.62/30, WAN2 72.211.21.217/27) both full-duplex, no gateway loss/down events;
PF states 28-31k/790k; load 0.6; 10-day uptime. Minor: igc3/WAN2 1707 Ierrs+Coll = Intel I225/226 2.5G
counter quirk (2.5G full-duplex active, no loss), not a fault. CONCLUSION: gateway/DHCP/DNS/WAN are not
bottlenecking WiFi — the 2.4 GHz RF remediation is the sole fix. Added "pfSense health check (2026-06-16)"
section to clients/cascades-tucson/reports/2026-06-16-unifi-full-audit.md.
### pfSense compat layer: pivot to SSH backend, OFF HOLD (Mike's call)
Mike (relayed by Howard): "we don't need the RESTAPI — VPN + SSH gets the same data and makes changes."
The earlier "pfSense too old for RESTAPI" premise was WRONG (it's 25.07, current). So the upgrade/package
blocker is moot; layer off hold. Built scripts/pfsense-ssh.sh (audit | dhcp | run "<cmd>"); cred from
clients/<slug>/pfsense-firewall; system OpenSSH via askpass; validated live on Cascades (the health data
above came from it). ROADMAP §E + SKILL.md updated to the SSH decision; REST pfsense-backend.sh left
dormant/optional. Closed obsolete coord todo afbe6a22 (upgrade-for-RESTAPI). Remaining = named gated
CONTROL verbs over SSH (easyrule block-ips, pf/fw toggles) — Howard: "leave that up to Mike" (his §E).
Commits: 58ecc5a (pfSense-ssh + health + off-hold), e42ad8f (memory).
### Still open (the actual WiFi win)
Tonight's 2.4 remediation per the runbook (reports/2026-06-16-2.4ghz-remediation-runbook.md): scope
(power-down-all + pilot one floor vs all 25) + whether Claude runs validation gates live during execution.