Did it right this time: completed the full channel survey (74/74) FIRST, let the
data choose. Survey proved DFS channels are 4-5x cleaner here (2-3% busy) than
non-DFS (149/157 = 12-28%, the property's worst). Per Howard: built the plan on
the 8 clean DFS 40MHz blocks (52/60/100/108/116/124/132/140), per-AP locally-
cleanest + neighbor graph-colored -> 0 co-channel, 3.5% avg busy. Applied to 72
non-mesh APs (width 40 too); mesh excluded; voice nudged back to 5GHz.
VALIDATED: 5GHz retry 8.7->3.8 avg (-56%), median 8.2->2.1 (-74%); 2.4 ~baseline;
satisfaction median 99; voice 31/31 (17 Poly on 5GHz, 3 coverage-cases on 2.4);
all 72 APs holding DFS, 0 radar vacates.
Kept tonight: 2b (2.4 power) + DFS plan + BSS-transition. 6GHz still WPA3-blocked.
auto_upgrade still OFF. Follow-up: recurring dfs-check radar monitor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Correction to earlier "deferred" report: after Howard pushed (5GHz needs fixing
regardless of 6GHz), I attempted width40 + non-DFS channel plan autonomously.
It did NOT validate live: 5G retry flat (8.7->8.4), 2.4 retry up (12->16) from
voice phones scattering to 2.4. ROOT CAUSE: the non-DFS channels here (149/157)
carry the heaviest EXTERNAL interference while DFS was cleaner -> forcing non-DFS
traded clean DFS for congested non-DFS. Rolled 5GHz back to baseline (channel+80MHz).
Kicked the 8 stuck Poly phones -> 6 back to 5GHz (rest are coverage-gap rooms).
End state recovered: satisfaction 98.4/med99, voice 31/31. Kept: 2b (2.4 power)
+ BSS-transition. 5GHz unchanged from start. auto_upgrade left OFF.
Doing 5GHz right needs the per-channel survey (choose channels by real cleanliness,
not non-DFS policy), reconsider non-DFS-only, 6GHz unblock (WPA3), band-steer voice.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Read-only Phase 0 baseline extended to floors 5/6 (MemCare). Findings:
- MemCare = same 3 diseases as 1-4 but untreated (2.4 at full power, not
over-thinned; all 5GHz on DFS+80MHz; min-RSSI off everywhere; 6GHz dark;
Shelby .218 stuck on 2.4 at Nurse Station).
- 5GHz static non-DFS channel-plan dry-run: co-channel pairs 19 -> 0 (kills
auto on all non-mesh APs; relieves AP 103/505 as fall-out).
- 2.4 1/6/11 re-color NEGATIVE right now (22 -> 28); defer until 2b restores
a stable Medium-power radio set.
- 7-day hour-of-day traffic: ~600 clients 24/7 (only ~10% swing); trough
01:00-04:00 MST. Change window decided: 2 AM start.
No changes applied. Survey stalled 68/74 (re-run before any 5GHz channel apply).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The 2026-06-18 repo restructure (history rewrite + project->submodule split)
dropped these 4 Cascades files from the new clone. Copied byte-identical from
the pre-cutover claudetools.old clone (md5-verified):
- docs/network/network-optimization-master-plan.md
- docs/network/phase1-voice-qos-design.md
- reports/2026-06-18-voice-quality-diagnostic.md
- session-logs/2026-06/2026-06-18-howard-cascades-rf-voice-optimization-plan.md
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocated verbatim from .claude/CLAUDE.md so the ad2 fork stops editing the
shared fleet harness doc. After rebase onto main, .claude/CLAUDE.md = the lean
fleet version; Dataforth ops context lives here. Keeps future ad2 syncs clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- apply-wlan.sh: wlan_bands token was "6e" but this controller stores "6g" (verified live on Cascades
Guest SSID) -> setting 6 GHz membership would have failed. Fixed band values + option names (5g6g/6g/all).
- Cascades 2.4 runbook: folded in Phase 5 (5 GHz: width 80->40 on 76 radios; channel plan with the
DFS decision flagged -- DFS empirically clean here, so including clean-DFS gives ~20 channels vs ~5
non-DFS-only for 77 APs) and Phase 6 (6 GHz: root cause = production SSID CSCNet not on 6 GHz [bands
2g,5g only]; add 6g + enable bss-transition; band-steering already on). Per Howard.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
DECISION (Mike, 2026-06-16): drop the RESTAPI package — VPN + SSH shell reads the same data and makes
changes. Confirmed Cascades pfSense is Plus 25.07-RELEASE (current; the "too old" premise was wrong) and
admin SSH = real shell (no menu). The upgrade/package blocker is moot; compat layer is off hold.
- NEW scripts/pfsense-ssh.sh: audit (version/WAN-media/gateway-events/DHCP-exhaustion/states/DNS/load/NIC),
dhcp (pool utilization + no-free-leases), run "<cmd>" (arbitrary, incl changes; operator-gated). Cred
from clients/<slug>/pfsense-firewall; system OpenSSH via askpass. Validated live on Cascades.
- audit report: added "pfSense health check (2026-06-16)" — DHCP NOT exhausted (192.168.0.0/22 pool 270/507,
0 no-free-leases), DNS up, dual-WAN stable (no gateway flaps), states/load healthy => gateway is NOT a
WiFi factor; the 2.4 GHz RF work is the sole fix. (Minor: igc3/WAN2 I225 2.5G counter quirk, not a fault.)
- ROADMAP §E + SKILL.md updated to the SSH backend decision; REST pfsense-backend.sh kept dormant/optional.
- Remaining: named gated CONTROL verbs over SSH (easyrule block-ips, pf/fw toggles) + optional gw-* dispatch.
- Closed obsolete coord todo (upgrade-pfSense-for-RESTAPI).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
First onboarding-diagnostic baseline for GND-SERVER (Grabb & Durando DC/file/RRAS box,
gd.local, 192.168.242.200). Grade RED: 2 critical (host firewall OFF on all profiles;
OS-EOL flag — false positive, build 17763 is Server 2019, supported to 2029), 6 warning
(Defender/AV unconfirmed, built-in Administrator enabled, 1 pending update, 2 disk errors
/14d, pending reboot, 2 stopped auto services), plus tempadmin local admin + no confirmed
BitLocker. Immutable JSON + report under onboarding-baselines/.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
