Wireless problems we solve
Wi-Fi Roaming Problems and Sticky Clients
The client decides when to roam. Infrastructure can only influence that decision through cell design, power, data rates and 802.11k/v/r assistance.
Engineer’s questionWhy are clients sticking to an access point instead of roaming?
1 — Direct answer
The short answer
Roaming is a client-side decision in 802.11. No controller can force a well-behaved client to leave an AP; it can only change the conditions the client uses to make the decision, and offer assistance through 802.11k neighbour reports, 802.11v BSS transition management and 802.11r fast transition.
Sticky behaviour is therefore almost always a design symptom: cells are larger than intended, transmit power is too high, low basic rates keep distant clients associated, or there is simply no better candidate AP for the client to move to.
Before changing anything, establish whether the client is staying too long, roaming too often, or roaming correctly but suffering an authentication delay each time — these three have completely different fixes.
Likely causes, roughly in order of frequency
- Cells too large / transmit power too high
- High AP transmit power extends usable coverage far past the intended cell edge, so clients never see a compelling reason to roam.
- Low basic/mandatory data rates enabled
- Leaving 1–11 Mbps enabled lets clients cling to distant APs at very low MCS, consuming airtime and degrading their own experience.
- No better candidate AP
- In corridor, high-ceiling or perimeter areas the 'sticky' client may genuinely have no stronger alternative — this is a coverage design issue.
- Missing roaming assistance
- Without 802.11k neighbour reports the client must scan blindly; without 802.11v the infrastructure cannot suggest a move.
- Authentication delay on roam
- Where 802.11r is absent and EAP re-authentication runs in full, each roam costs hundreds of milliseconds — enough to break voice and session applications.
- Client driver and power-save behaviour
- Roaming thresholds and scan behaviour vary widely by chipset, driver version and OS power settings, and cannot be assumed uniform.
2 — Symptoms
Symptoms and what they usually mean
| Symptom | What it usually indicates |
|---|---|
| Client stays on a far AP at −80 dBm with a closer AP available | Cell design and power, or missing roaming assistance. |
| Performance recovers only after disabling and re-enabling Wi-Fi | Classic sticky-client signature. |
| Rapid ping-ponging between two APs | The opposite failure — overlapping cells of near-equal signal, often from excessive AP density. |
| Voice calls break exactly at a roam | Roam latency, usually authentication or channel-scan time, not coverage. |
| Only one device family is affected | Client-side roaming thresholds; infrastructure changes will have limited effect. |
3 — Do this first
Safe checks you can run yourself
These are non-disruptive checks a competent network engineer can complete with the controller or cloud dashboard already in place. Do them before changing configuration — they frequently identify the cause, and they always make an external investigation faster and cheaper.
- 1
Pull client roam history from the controller
RSSI at the moment of roam, target AP and time between roams tells you which of the three failure modes you have.
- 2
Review transmit power ranges in the RF profile
Check both the maximum and minimum RRM power settings, and whether they differ between bands.
- 3
Check enabled basic and supported rates
Disabling the lowest legacy rates is one of the highest-value, lowest-risk changes in most enterprise WLANs.
- 4
Confirm 802.11k/v/r are enabled and advertised
And confirm the client population supports them; mixed support requires care with legacy devices.
- 5
Measure the actual roam gap
A continuous ping or a voice test walked across the boundary shows the real interruption duration.
- 6
Verify RADIUS placement and response time
A remote or slow authentication server converts every roam into a user-visible pause.
4 — Watch out
Common mistakes and misleading indicators
“We enabled client steering, so roaming is handled”
Steering influences band and AP selection at association; it does not control roam timing for an already-connected client.
“Turning power to maximum improves mobility”
It usually harms it — larger cells, more co-channel interference and later roaming decisions.
“The client shows −65 dBm, so the roam was fine”
The value reported after the roam says nothing about the gap duration during it.
“802.11r is enabled, so roaming is fast”
Only if the client supports and uses the same FT method; mixed-mode deployments frequently fall back to full authentication.
5 — Escalation point
When normal troubleshooting is no longer enough
- Voice, video or real-time applications are breaking at roam boundaries.
- Roam behaviour differs between device types and you need a design that serves all of them.
- Power and channel changes have produced unpredictable results across the floor.
- You need packet-level evidence of what is happening during the roam exchange.
- The environment has both sticky clients in some areas and ping-ponging in others — a design conflict that needs measurement to resolve.
6 — Professional investigation
What a professional wireless investigation should measure
- Active roaming survey
- Walked and driven roaming measurement recording association events, RSSI at roam, roam duration and packet loss across boundaries.
- Over-the-air packet capture
- Capture of probe, authentication, association, FT and BSS-transition exchanges to measure the real roam cost.
- Cell-edge and overlap analysis
- Measured primary and secondary coverage, overlap percentage and cell-edge SNR against the mobility requirement.
- RF profile and RRM review
- Transmit power ranges, channel widths, data rates, RRM behaviour, band steering, load balancing and roaming assist configuration.
- Authentication path review
- EAP method, RADIUS placement, session caching, PMK/OKC and 802.11r configuration end to end.
- Client behaviour profiling
- How the actual deployed device families behave against the design, rather than a generic assumption.
7 — Relevant service
Which NetRobin service applies
Wi-Fi Troubleshooting
Roaming faults sit across RF design, controller configuration, authentication and client behaviour. A troubleshooting engagement measures all four and identifies which one is actually producing the user-visible failure.
Often combined with
8 — Deliverables
What you should expect to receive
- Measured roaming behaviour and roam durations across the affected areas
- Cell-edge, overlap and transmit power findings with recommended targets
- Authentication and fast-transition findings
- Prioritised configuration and design recommendations
- Re-test criteria to confirm the improvement
Direct answers
Frequently asked questions
- Why are clients sticking to an access point?
- Because the client, not the infrastructure, decides when to roam, and it has no strong reason to move. Oversized cells, high transmit power, low enabled data rates and missing 802.11k/v assistance all let a client hold a distant AP well past the point where performance has degraded.
- Can a controller force a client to roam?
- Not reliably. 802.11v BSS transition management can request a move and some platforms will de-authenticate a client as a last resort, but a client may ignore or immediately re-associate. Sustainable fixes come from cell design, transmit power and data-rate configuration.
- How fast should an enterprise Wi-Fi roam be?
- For voice and real-time applications the target is typically under about 50 ms of interruption, which generally requires fast transition and a well-designed cell edge. Data-only environments tolerate considerably more.
10 — Next step
Discuss a Wireless Problem
Bring your roam logs and floor plan — we will tell you whether this is a design, configuration or client issue.