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 13:30:26

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-16 13:30:26
This commit is contained in:
Howard Enos
2026-06-16 13:30:35 -07:00
parent 2f6057518d
commit 0956f76cb2
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -547,3 +547,31 @@ EXPECTATION SET: 2.4 cu_total won't plummet (channel is foreign-dominated, ~33k
is cell-shrink + reduced SELF-interference + better client SNR, seen in retry%/consolidation over ~10-15 is cell-shrink + reduced SELF-interference + better client SNR, seen in retry%/consolidation over ~10-15
min, and it sets up the Phase-C disables. Next: settle ~15 min, re-snapshot Floor-4 retry% for before/after; min, and it sets up the Phase-C disables. Next: settle ~15 min, re-snapshot Floor-4 retry% for before/after;
decide on 445 (poe-cycle to apply low, or leave). Disables (445/428) still HELD. decide on 445 (poe-cycle to apply low, or leave). Disables (445/428) still HELD.
---
## Update: 2026-06-16 13:30 PT — Floor-4 pilot RESULT (15-min settle) + pfSense-access review + VPN flap
FLOOR-4 power-down before/after (controller live-stats, via Tailscale — unaffected by the Cascades VPN flap):
avg 2.4 retry%: 13.2 -> 9.5 (~28% fewer retransmits); avg cu_total 86 -> 83% (small, channel is
foreign-dominated as expected); clients RETAINED (no coverage loss). Big per-AP retry wins: 407 21->0,
4th Floor Atrium 27->0, 434 22->7; a few bounced up (403/428/421) = instantaneous-snapshot jitter as
clients re-associate. Caveat: single 15-min snapshot is noisy; direction is positive + safe. Pilot = success.
(445 still at 30dBm not converged — left alone.)
PFSENSE-ACCESS REVIEW (Howard asked, given pfSense+UniFi access): KEY GAP — Cascades' gateway/WAN/DHCP/
DNS/firewall is 100% pfSense; gw-audit/gw-control are UniFi-only (num_gw=0) so we've audited NONE of it.
We have pfSense creds but NO path from Howard-Home: Cascades 192.168.0.0/24 (pfSense .0.1, NAS .0.120) is
shadowed by Howard's HOME UniFi network (also 192.168.0.0/24; .0.1 = home UniFi console cert unifi.local).
APs/CS-SERVER (.2.x/.3.x) work via the /22 tunnel route. Likely hidden non-RF contributors to "bad for
some users": DHCP pool exhaustion (per-room /28 VLANs + 587 clients), DNS latency, dual-WAN (Cox Fiber+Coax)
health/failover, inter-VLAN firewall. RF plan stays valid but don't declare "fixed" on RF alone.
THE MISS (skill): gateway verbs are UniFi-REST only; our real topology is UniFi-behind-pfSense (Cascades,
office, several clients) = Mike's ROADMAP §E pfSense compat layer = highest-value next build.
/32 ROUTE: added 192.168.0.1/32 via tunnel (192.168.10.1) to reach Cascades pfSense; REMOVED it again
when the VPN started flapping (don't tie home gateway IP to an unstable tunnel). pfSense untouched throughout.
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).