A handheld at city hall stays associated to a distant AP with strong reported RSSI while a nearer AP is ignored, and probes/roams are rare in the capture. What pattern is this?
Select an answer to reveal the explanation.
Short Explanation
Sticky clients are the coworker who won’t leave the far printer even though a closer one is free—bars still look fine, so they never walk over. Captures with rare probes and stubborn far-AP associations tell that story.
Full Explanation
A handheld at city hall that stays associated to a distant AP with strong reported RSSI while ignoring a nearer AP, with rare probes/roams in the capture, exhibits sticky-client behavior. The device retains a far association and shows little roam/probe logic despite a better local AP. Expert diagnosis uses the scarcity of roam attempts plus far-BSSID persistence, then tunes RF overlap, minimum RSSI, or client roam settings.
Calling it mandatory FT failure because sticky clients never use Authentication frames of any kind over-constrains sticky behavior to FT and incorrectly bans auth frames. Claiming hidden SSIDs prevent sticky behavior by removing all BSSID fields is false—sticky clients associate to BSSIDs regardless of broadcast SSID. Saying EDCA VO is disabled whenever RSSI exceeds −40 dBm invents a QoS rule unrelated to sticky roam logic.
Exam caveat: sticky clients are a roam-policy/RF-design issue visible in sparse probe/roam timelines. Operational check: capture the sticky handheld near the closer city-hall AP, confirm continued data to the far BSSID with few probes, then adjust cell overlap or client roam aggressiveness and retest handoff. If sticky behavior is client-OS specific, document the handheld model and roam settings in the city-hall WLAN known-issues list for helpdesk scripts.