Monitoring for a city clinic WLAN shows client MCS distributions skewed low even though RSSI histograms look healthy. Retries are elevated. What should the expert investigate first?
Select an answer to reveal the explanation.
Short Explanation
Strong signal strength with weak data rates is like yelling across a noisy cafeteria—you’re loud, but nobody understands you. Low MCS with OK RSSI usually means interference, collisions, or a cranky client. Chase the noise and retries, not the captive-portal wallpaper.
Full Explanation
When associated RSSI looks fine yet municipal clients show rising data retries and falling MCS, the expert should investigate interference, collisions, or client/driver issues that degrade SNR effectiveness despite adequate RSSI readings. RSSI alone does not guarantee clean airtime or successful decoding under noise and contention. Whether captive portal HTML is too large may affect guest redirect time but does not explain post-association retry/MCS collapse for already-connected staff clients. Whether NTP stratum on the controller matches GPS atomic time matters for logs and certificates, not as the primary RF retry diagnosis. Whether PoE silk-screen labels are bilingual is irrelevant to wireless PHY performance. Exam caveat: separate RSSI coverage from noise, retries, and MCS—CWNE triage uses multiple RF and KPI views. Operational check: correlate retries with spectrum busy, CCI, and client driver versions during the failure window, remediate interference or client issues, and re-validate application performance for civic users before closing the ticket. In municipal WLAN operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current controller code, client mix, and civic event calendar used by the wireless team.