Cascades — voice VLAN migration COMPLETE (29/29 Poly) + per-phone diagnosis + Vertical 5 GHz handoff

User

User: Howard Enos (howard)
Machine: Howard-Home
Role: tech

Session Summary

Daytime follow-on to the overnight RF optimization (see 2026-06-19-howard-cascades-rf-night-capstone.md and ...-5ghz-dfs-datadriven-applied.md). Three things got done: (1) finished the voice VLAN migration — every Poly handset is now on VLAN 30; (2) re-centered on the actual goal (clean voice calls) with a per-phone diagnosis, which revealed the residual problem is band selection, not RF; (3) handed the band fix to the VoIP vendor (Vertical) via a 5 GHz-only request, now pending their response.

Voice VLAN migration finished. The 6 stragglers found 2026-06-18 (Poly phones still on VLAN 20 / the .1 net) were identified onsite by Howard and re-keyed to the voice PPSK, plus 2 phones added during the walk: Zachary Nelson (Accounting Asst, .232), Recreation room rm132 (.233), Movie Theater 2nd-fl (.234), Library 4th-fl (.235), Bistro (.236), John Trozzi rm422 (.237), and the Kitchen server's phone. Final: 29/29 Poly on VLAN 30 + 8/8 AudioCodes (.224-.231) + Vertical desktop (.201). Full named inventory in docs/network/voice-phone-inventory.md.

Per-phone voice diagnosis (the re-look Howard pushed for). Fleet averages were misleading; the goal is the Poly phones. Pulled live per-phone state and compared to the 2026-06-18 diagnostic. Most phones are fine on the clean 5 GHz (Lauren .202, the worst original case, went 2.4/50% retry -> 5GHz/12%). BUT several handsets are stuck on 2.4 GHz despite EXCELLENT signal (-50 to -60 dBm) at 36-96% retry — including two (.209, .212) that were healthy on 5 GHz before our channel churn and got displaced to 2.4 and stuck. This is a band-selection problem, not RF/coverage — and controller-side band steering (no2ghz_oui, already ON) is not holding the Poly fleet on 5 GHz. No channel/power/min-rate tuning fixes which band a phone chooses.

Vendor handoff. Wrote + sent (Howard) a short request to Richard Turner (Vertical) to set the Poly handsets to 5 GHz-only (disable 2.4 GHz in provisioning) — the reliable fix to keep them on the clean band. Letter: docs/network/2026-06-19-vertical-5ghz-lock-request.md. Status: waiting on Vertical. Once pushed, the calls close out end-to-end (clean voice VLAN + clean 5 GHz band).

Also confirmed (data-driven) that the 2.4 channel re-plan is NOT a useful lever here, and ran fleet self-check to GREEN after pulling the b668430 baseline fixes.

Key Decisions

5 GHz-only band lock is the #1 remaining voice action, handled phone-side by Vertical — not more controller tuning. Band steering is already on and isn't holding the Poly OUI (48:25:67) on 5 GHz.
2.4 channel re-plan: NOT worth doing. Scan showed every 2.4 channel is 84-91% busy (external saturation); our co-channel could go 31->7 but it's a thin slice of an already-full channel, so retry won't move. Band-steering (already on) + the deferred min-rate raise are the only real 2.4 levers, and even those are marginal against the external density.
Verify VLAN membership via the client vlan field, not the controller's displayed IP — the IP field caches/lags (the Kitchen server phone showed a stale 192.168.1.126 while actually on vlan:30).

Problems Encountered

Misread the Kitchen server phone as off-voice because I keyed on the controller's cached IP (192.168.1.126) instead of its vlan:30 field. Howard was right that it was on voice. Fix: check the vlan field / pfSense lease, not the displayed IP. (Logged as the gotcha in the inventory.)
Two phones (.209, .212) regressed 5GHz->2.4 during the overnight channel churn and stuck on 2.4 — underscoring that band selection needs the phone-side lock, not RF tuning.
My earlier 2.4 proposals were wrong on the facts (proposed enabling band-steering that was already on; proposed a min-rate value without checking it was already set to 1 Mbps). Corrected after pulling the actual WLAN config.

Configuration Changes

No controller config changes this session — all reads/diagnosis. The phone re-keys were done on-handset by Howard (voice PPSK). 29/29 Poly now on VLAN 30.
Docs: docs/network/voice-phone-inventory.md updated to the full named 29-phone roster + completion; docs/network/2026-06-19-vertical-5ghz-lock-request.md created (the Vertical letter).
Earlier today (separate logs/commits): 2.4 power->medium + 5 GHz clean-DFS plan applied + validated; unifi-wifi skill hardened (survey-report.py + data-driven channel-plan); self-check GREEN.

Credentials & Secrets

No new credentials. Voice PPSK (Poly WiFi) is vaulted at clients/cascades-tucson/wifi-voice-ppsk.
Used infrastructure/uos-server-network-api-rw (controller) + clients/cascades-tucson/pfsense-firewall.

Infrastructure & Servers

VOICE VLAN 30 (10.0.30.0/24): 29 Poly (.202-.223, .232-.237) + 8 AudioCodes (.224-.231) + Vertical desktop (.201). Controller 172.16.3.29 site va6iba3v.
Poly OUI 48:25:67; AudioCodes OUI 00:90:8f. Band-steering no2ghz_oui:true on CSCNet + CSC ENT (not holding Poly on 5 GHz). 2.4 min-rate = 1 Mbps / pref auto. 5 GHz = clean DFS 40 MHz.

Pending / Incomplete Tasks

Vertical: set Poly handsets 5 GHz-only (request sent; awaiting Richard Turner). The last voice item.
After Vertical pushes it: re-pull per-phone data, confirm every handset on 5 GHz + retry drops.
Investigate .210 anomaly (5 GHz, -65 dBm, ~64% retry on a clean channel — AP-217 or per-phone issue).
(Lower priority, unchanged) 6 GHz blocked on WPA3; re-enable 3 AM AP auto-upgrade; DFS radar monitor; MemCare min-RSSI after next week's new APs; fill the Kitchen-server/Library/Bistro display IPs on renew.

Reference Information

Inventory: docs/network/voice-phone-inventory.md. Vertical letter: docs/network/2026-06-19-vertical-5ghz-lock-request.md.
Voice-quality diagnostic (orig): reports/2026-06-18-voice-quality-diagnostic.md.
Today's commits: 7ff723d (DFS plan), fb835fe (skill hardening), a5ce67b (wiki), 2a7253a (Vertical letter), 5afe99e..a5d47be (voice inventory re-key updates).

6.2 KiB Raw Blame History