Sticky client holding a distant access point
The client, not the network, decides when to roam, so a device can hold on to a fading access point until the link fails instead of moving to the closer one it already passed.
On this page5 sections
Is this your problem? It presents like this
- The device drops after it has passed a closer access point, not in a coverage hole.
- Before the drop, its signal and data rate on the current access point fall steadily while another access point nearby is much stronger.
- Retries climb and throughput collapses before the disconnect.
- One client model shows it far more than others on the same route.
- After the drop, the device reconnects to the nearer access point straight away.
- Bands
- 2.4 GHz5 GHz5 GHz DFS6 GHz
Why it happens
The roam decision belongs to the client. Even an infrastructure vendor’s roaming guide says so: it is always the wireless client that selects which AP is preferred. The network can suggest a better access point. It cannot move the client.
Each client vendor sets its own trigger. Apple documents that an iPhone or iPad holds its access point until the signal passes -70 dBm1, a Mac until -75 dBm, and that a candidate must be 8 to 12 dB stronger before an iPhone moves. Intel’s Windows driver has a roaming aggressiveness setting whose lowest value waits until the signal is very low. On Linux, wpa_supplicant only looks for a better access point as often as its background scan module is told to, and that module can be switched off.
A conservative trigger makes sense for a laptop on a desk, where a needless roam costs more than a weak link. On a vehicle crossing cells, the trigger can fire after the best access point is already behind it. The problem is common enough that infrastructure vendors sell a countermeasure. One vendor’s low-signal disconnect feature exists to fix sticky clients that remain associated to access points that are far away. It does that by disconnecting them, not by roaming them.
Vehicle makers have built the same fix into the client, and it cuts both ways. One AMR maker’s older software offers a signal strength watchdog that forces a reassociation when the signal dips below a set threshold. Its guide warns that a threshold the robot cannot reach makes it force roam after roam, and the Wi-Fi connection drops again and again for no reason. Set the trigger too late and the vehicle holds a distant access point. Set it beyond reach and the vehicle drops a healthy link.
On AGVs, signal loss is what starts the roam. In a study of AGV disconnections at an automotive plant, roam trigger messages such as LOW RSSI and BEACON MISS appeared in 89.46%2 of the events. A client that waits for its link to fail before it looks for the next access point starts the search already disconnected.
The sticky client
The client decides when to roam. Past the crossover the new access point is stronger, but the client stays until its own threshold says go.
Schematic, not to scale
Shape only: no measured levels, and no particular client's threshold. The client selects the access point and holds its current one until the signal passes its own threshold, which differs by platform and setting. Network features meant to fix sticky clients work by disconnecting them. The sources are on the sticky client page.
How to confirm it
- Pull the client's connection history for the minutes before the drop. Record the access point, signal, and data rate.
- Compare the client's signal at the moment of the drop with a survey reading for the nearest access point at that spot.
- Check the client's roaming settings. Look at the roam trigger threshold, the roaming aggressiveness setting, and whether background scanning is on.
- Drive the same route with a second client model and compare where each one roams.
- Check whether the network sends 802.11k neighbor reports and 802.11v transition requests, and whether the client acts on them.
The fix
- Raise the client's roaming aggressiveness, or move its roam trigger to a stronger signal, where the driver exposes the setting.
- Enable 802.11k neighbor reports and 802.11v transition requests if the client supports them.
- Use a network-side low-signal disconnect only after testing it with your clients. It forces a full reconnect, not a roam.
- Update the client driver if the vendor documents a roaming fix.
Prevent it at design time
- Ask every mobile client vendor what roam trigger their driver uses, and write the answer into the purchase.
- Design cell overlap so the next access point is clearly stronger at the point where the client's trigger fires.
- Test roaming along every production route with each client model before go-live.
About this page
Built from 7 sources: 1 research paper or thesis and 6 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Sticky client holding a distant access point." OT Wireless, published October 5, 2026. https://otwireless.com/causes/sticky-client/
APA 7
Rutter, B. (2026, October 5). Sticky client holding a distant access point. OT Wireless. https://otwireless.com/causes/sticky-client/
BibTeX
@misc{rutter2026stickyclient,
author = {Rutter, Ben},
title = {{Sticky client holding a distant access point}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/sticky-client/}},
organization = {OT Wireless},
}