Band Steering and Sticky Clients
The client decides. The AP suggests. Neither always wins.
The 802.11 specification gives the client full authority over when to roam. An AP can suggest - through 802.11v BSS Transition Management - but cannot command. Sticky clients exploit this: they hold onto a distant AP long after a closer one would serve them better. Band steering covers all the AP-side techniques for nudging clients where you want them. None of them reliably work on every client.
The client is in charge
IEEE 802.11 places roaming decisions entirely with the client (STA). The AP cannot force a client to roam. It can only: refuse associations, send BSS Transition Requests (802.11v), or as a last resort, deauthenticate - but deauthentication breaks the session and is not a graceful handoff.
A "sticky client" is one that remains associated to an AP with deteriorating RSSI when a better AP is available. The client's roaming algorithm - implemented in the driver and firmware - decides when to scan and when to roam. Enterprise APs have no standard mechanism to override this.
Client-side roaming decisions
- Driver roaming threshold not reached - client only scans when RSSI drops below an internal threshold, often -75 to -80 dBm
- Scan cost - background scanning interrupts TX/RX, some clients avoid it during active traffic
- False comfort - client RSSI is measured at the client antenna, not the AP; asymmetric link quality confuses the decision
- IoT and legacy clients - many lack 802.11v/k support and have fixed roaming thresholds that are too conservative
- Mobile OS policies - iOS and Android both limit background scanning to preserve battery, delaying roaming decisions
What sticky clients cost
- Low MCS on sticky client's frames - distant AP transmits at MCS 0-2, consuming large amounts of airtime per frame
- Airtime starvation for other clients - one sticky client at MCS 1 uses the same airtime as six clients at MCS 7
- VoIP SLA breach - 802.11r FT roaming not triggered, authentication latency spikes during forced reassociation
- AP coverage hole appearance - coverage maps show a hole where the far AP RSSI is poor, masking the real cause
- Hidden retry amplification - sticky client retransmits repeatedly, each retry consuming channel airtime
Band steering vs roaming steering
The term "band steering" is used for two distinct functions that are often conflated:
Moving a client from 2.4 GHz to 5 GHz (or 5 to 6 GHz) on the same AP. Goal: higher throughput, less interference. Method: suppress probe responses on 2.4 GHz, or send BTM Request pointing to 5 GHz BSSID.
Moving a client from one AP to another AP in the same ESS. Goal: better coverage, load balancing. Method: 802.11v BTM Request pointing to neighbour AP BSSID. Often called "optimised roaming" by vendors.
BSS Transition Management
802.11v BSS Transition Management (BTM) is the standard mechanism for APs to suggest a roam to a client. It uses Action frames in the Wireless Network Management (WNM) category. The client advertises BTM support in its association request - the AP checks this flag before sending.
Client sends a BTM Query Action frame to the AP to request a candidate list. Category: 10 (WNM), Action: 6. Includes Query Reason Code (e.g., 4 = leaving ESS).
AP sends a BTM Request Action frame. Contains candidate AP list with BSSIDs, RSSI preference, channel info. Key fields: Disassoc Imminent bit, Disassoc Timer, BSS Termination Duration, Session Info URL.
Client responds with accept or reject. Status Code 0 = will transition, non-zero = reject with reason. Client may include its own Target BSSID preference. Even if client accepts, the actual roam may take hundreds of milliseconds.
If the client rejects the BTM Request and Disassoc Imminent was set, the AP may send a Deauthentication frame when the Disassoc Timer expires. This breaks the session. Not graceful. Vendors call this "forced roaming" or "anti-sticky." It is the AP's only coercive option and is not defined as a BTM outcome in the standard.
BTM Request key fields
Vendor implementations
Band steering is not standardised beyond the BTM frame mechanics. Every vendor has proprietary thresholds, trigger logic, and override behaviour. Defaults and feature names change across firmware versions - treat this as a starting point, not a config guide.
- Triggered when client RSSI drops below configured threshold (default -80 dBm)
- Sends BTM Request with candidate list from 802.11k Neighbor Report
- If client rejects, Coverage Hole Detection can trigger deauth
- Requires Coverage Hole Detection enabled on same radio band
- CLI:
wireless client band-select, threshold per radio
- Adaptive Radio Management (ARM) handles band and AP steering centrally
- Suppresses 2.4 GHz probe responses for capable clients to force 5 GHz association
- Uses 802.11v BTM for inter-AP roaming with centrally computed candidate lists
- Client match: groups clients by type (IoT, voice, data) and applies per-group thresholds
- CLI:
band-steering mode(force / prefer / disable)
- Configurable RSSI threshold per band (5 GHz default -45 dBm per documentation)
- Sends BTM Request if client supports 802.11v, else deauthentication
- voice-enterprise enables sticky-client-remove automatically
- CLI:
sticky-client-remove enable,sticky-client-threshold-5g "-65"
- SmartRoam monitors client RSSI and sends BTM Requests below threshold
- BSS Min Rate (data rate threshold) prevents low-MCS clients from associating, forcing them to roam
- Band Balancing: discourages 2.4 GHz associations by limiting 2.4 GHz bandwidth
- RF signature: identifies client device type to apply appropriate steering policy
- Mist uses ML to predict client roaming decisions based on historical RSSI patterns
- 802.11v BTM sent proactively before RSSI degrades (predictive steering)
- Client event timeline in Mist dashboard shows BTM Request/Response per client
- Marvis virtual assistant flags sticky client anomalies in site-wide reports
- iOS (Apple): Accepts BTM Requests in most cases, especially below -70 dBm. Does not accept deauthentication as a graceful roam trigger. 802.11r FT required for seamless voice continuity.
- Android: Variable - manufacturer implementation differs. Google Pixel tends to roam aggressively. Samsung often requires -80 dBm before scanning. IoT Android devices (TV, Cast) may have fixed -80 dBm threshold hardcoded.
- Windows: Configurable via netsh but defaults vary. Enterprise clients with 802.11v support typically accept BTM. Consumer drivers (Qualcomm QCOMxx) are more aggressive than Intel.
- IoT (ESP32, lwIP): No 802.11v support. No BTM capability. Deauthentication is the only option and typically triggers reconnect to same AP if RSSI is above connection threshold.
Reading band steering in a PCAP
BTM frames are Action frames in WNM category (Category 10). They appear in a PCAP only if you are capturing on the correct channel and the client is within range. A monitor-mode capture on the serving AP channel will show the full exchange.
All BSS Transition Management frames use Action frame category 10 (WNM). This filter catches Request, Response, and Query in one view.
wlan.fixed.category_code == 10 wlan.fixed.category_code == 10 && wlan.fixed.action_code == 7 wlan.fixed.category_code == 10 && wlan.fixed.action_code == 8 Dialog Token ties a BTM Request to its Response. Filter by token to trace a specific steering exchange. Status 0 = client accepted. Non-zero = rejected.
wlan.fixed.btm_response_status_code != 0 (wlan.fixed.category_code == 10) && (wlan.ra == client:mac || wlan.ta == client:mac) If a vendor uses forced deauthentication to move sticky clients, the sequence is: low RSSI on client frames, BTM Request, BTM Response (reject), then Deauth. Reason code 3 (STA leaving) or 12 (inactivity) is typical.
wlan.fc.type_subtype == 0x000c && wlan.ta == ap:bssid wlan.fixed.reason_code == 3 A sticky client shows persistently low rate on data frames while the serving AP RSSI is weak. Cross-reference radiotap RSSI with data frame MCS to identify clients that should have roamed but didn't.
wlan.ta == client:mac && radiotap.dbm_antsignal < -75 && wlan.fc.type == 2 wlan.ta == client:mac && radiotap.datarate < 24 Band steering troubleshooting sequence
Check Association Request - Extended Capabilities IE bit 19 (BSS Transition). If 0, client does not support BTM and deauth is the only AP option.
Filter for Category 10, Action 7 from the AP BSSID to the client MAC. If absent, band steering threshold not met or feature disabled on AP.
Status 0 = accept. Non-zero = reject. If client rejects, check whether Disassoc Imminent bit was set in the Request - if yes, AP should follow up with deauth within the Disassoc Timer.
BTM Request should include at least one candidate BSSID with better RSSI than the current AP. If candidate list is empty or AP RSSI is similar, client may legitimately reject.
If the target AP does not support 802.11r FT, the client must perform full re-authentication after the transition. Latency spikes of 200-500ms are expected. Voice calls will drop. Enable FT on all APs in the ESS for seamless BTM transitions.