Clients hang onto the far AP
very common
“You walk from one end of the building to the other and the phone still clings to the AP you started on. Calls break up until you toggle Wi-Fi off and back on.”
Likely causes
-
Cells too hot: every radio at max power, so the old AP stays good enough at distance
30%Client holding an AP at -78 dBm three rooms back while a nearer AP is at -55 dBm. Radios all sitting at 20-23 dBm and the -67 dBm contour of one AP reaches past the next two.
-
No minimum-RSSI or client-steering policy configured
20%Controller shows one association surviving a 20-minute walk across the whole floor with no deauth at all. The low-RSSI kick is off, or set so low (-85 dBm) it never fires.
-
Client-side roaming logic: the decision was never yours
20%One phone model or one laptop adapter is sticky and everything else in the same walk roams cleanly. Many clients will not even start scanning until around -70 to -75 dBm and then want the candidate several dB better before they move. The exact trigger is driver-specific, so look up that client's published behaviour rather than assuming.
-
Fast roaming, neighbour reports and steering missing, or inconsistent across the SSID
15%The roam happens but takes 500 ms to 2 s and drops the call. A capture shows a full authentication from scratch on every roam instead of a fast transition exchange. Or fast transition is enabled on one AP group in the path and not the next.
-
It is 2.4 GHz doing the sticking
10%Client is holding a 2.4 GHz BSSID at -75 dBm with strong 5 GHz available in the same spot. 2.4 carries further, so that cell never gets bad enough to trigger a roam.
-
Coverage hole in between: the client has nowhere to go
5%Nothing on that SSID measures better than -72 dBm anywhere along the corridor. The client is not sticky, it is stranded.
What to bring
- Survey tool with walk-test logging
- phone Wi-Fi analyzer
- laptop with a monitor-mode capture adapter
- controller access
- a second known-good client device
Steps
-
Step 1: Walk the route with the complaining client, not with the survey laptop
Log RSSI and BSSID on the actual device that fails, along the actual path, at the actual height. Mark where it should have roamed and what it held instead. Voice wants about -67 dBm and 20-25 dB SNR at cell edge.
If that doesn’t do it
Device roams fine on your walk: get the user to reproduce it and note the time, then read the controller's client history for that window.
-
Step 2: Confirm there is a real second option at the sticking point
Stand where it fails and check that another AP on the same SSID and band is at least 8-10 dB stronger. If nothing is, you do not have a roaming problem.
If that doesn’t do it
No better AP available: this is coverage. Go to Heat map was green, the room is dead.
-
Step 3: Turn the cells down before you turn anything else up
5 GHz: cut TX power so the cell edge lands near -67 dBm (often the low-to-mid teens dBm indoors depending on antenna gain) and raise the minimum mandatory rate off 6 Mbps, typically to 12 or 24 Mbps, so beacons stop advertising the cell further than the data can work. 2.4 GHz is a separate job: that band is where the 1/2/5.5/11 Mbps 802.11b rates live and disabling them there does nothing to a 5 GHz radio. Raising the basic rate shrinks the usable cell, so re-walk the same route and watch for legacy kit you have just stranded.
If that doesn’t do it
Still sticking with tighter cells: move to policy, step 4.
-
Step 4: Set the roam-assist thresholds
Enable the low-RSSI or minimum-RSSI disassociation around -70 to -75 dBm, plus BSS transition steering if the platform has it. Knob names, units and defaults differ by vendor; read that controller's documentation instead of copying a number from another job.
If that doesn’t do it
Clients get kicked but immediately re-associate to the same far AP: the threshold is fighting a too-hot cell. Go back to step 3 and take more power out.
-
Step 5: Verify fast roaming end to end, not just on one AP
Enable the fast transition method your vendor supports (over-the-air or over-the-DS) and neighbour reports on the SSID across every AP group in the roam path, then confirm in a capture that roams are actually fast-transition exchanges. Watch legacy clients: fast transition on a mixed SSID can break association on older gear, so test a sample of what is really in the building.
If that doesn’t do it
Roams are fast transitions and still audible in a call: check the wired path and the voice VLAN, and whether the roam crosses a subnet boundary.
-
Step 6: Isolate the client
Repeat the identical walk with a second device of a different make. If that one roams cleanly, the fault is the driver or that adapter's roaming-aggressiveness setting: update the driver and raise the aggressiveness rather than re-engineering the RF.
If that doesn’t do it
Everything sticks after power, policy and fast transition are right: capture on the client's channels and check whether it is scanning at all. No probe requests on other channels means the client is not even looking.
References
- IEEE 802.11-2020 Cl.13 (fast roaming exchange)
- IEEE 802.11-2020 Cl.11 (radio measurement and client steering)
- TIA TSB-162-A