OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Fast roaming mismatch between client and network

802.11r, 802.11k, and 802.11v only help when both sides support them for the same key type and the same group of access points, and a mismatch quietly turns fast roams into slow ones or failed joins.

Ben RutterIndustrial network engineer
  • Updated
  • Reviewed
  • 2 min read
  • 4 sources
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Roams work for some client models and fail or crawl for others on the same SSID.
  • A newly added client model cannot join an SSID after fast transition was turned on.
  • Roams fail at a boundary between groups of access points, such as two controllers, AP groups, or buildings, and work everywhere else.
  • Captures show the client attempting a fast transition and then falling back to a full authentication, or a fast transition that times out.
  • Roaming got worse right after someone enabled or changed fast roaming settings.
Bands
2.4 GHz5 GHz5 GHz DFS6 GHz
Not sure?
Rank the likely causes from your symptoms

Why it happens

Fast transition is an agreement, not a switch. hostapd’s reference configuration defines the mobility domain as the group of APs between which a station can use fast BSS transition. A roam across that boundary is a full join. Inside it, the target access point still has to fetch the client’s key from the key holder that issued it, and hostapd waits 1 second1 by default for that answer before it retries.

Client support is uneven, and it differs by key type. Windows supports fast transition over 802.1X but not PSK2, and only when the radio driver supports it. Apple supports it with both PSK and 802.1X3, yet its Intel-based Macs don’t support Fast BSS Transition and only interoperate with it. One SSID can give fast roams to some devices and full reauthentication to the rest.

Turning fast transition on can also lock clients out. One vendor’s fast transition deployment guide warns that legacy clients cannot associate with a WLAN that has 802.11r enabled4 when the supplicant driver does not understand the extra key management suites. Mixed mode exists so those clients can still join, and they still roam without fast transition.

802.11k and 802.11v have the same catch: Microsoft notes they need AP-side support and don’t work unless they’re enabled on the APs. The roam is only as fast as the slowest combination of client model, key type, and access point group on the route.

Where a roam loses time

The outage runs from leaving the old access point until data flows on the new one.

Schematic, not to scale

leaves old APFull 802.1X roamauth + reassocfull EAP exchange with the auth server4-way handshakedata flowsoutage: no dataFast transition (802.11r)FT auth + reassocdata flowsoutage

Without fast roaming, every roam on an 802.1X network repeats the full EAP exchange with the authentication server; with EAP-TLS that is several request and response rounds carrying certificates. Fast BSS transition moves the key exchange into the authentication and reassociation frames, so fewer frames pass before data transfer. Widths show the order of the steps, not measured durations.

Sources: RFC 5216 (EAP-TLS) and Microsoft's Windows driver documentation on fast roaming.

How to confirm it

  1. List the key management suites the SSID advertises (802.1X, FT-802.1X, PSK, FT-PSK, SAE, FT-SAE) and compare them with what each client model's driver supports.
  2. Capture a roam. An FT authentication or FT reassociation means fast transition worked. An open authentication followed by EAP or a full 4-way handshake means it fell back.
  3. Check that every access point along the route advertises the same mobility domain, and that the key holders can reach each other.
  4. Check whether failures cluster at a boundary between controllers, AP groups, or sites.
  5. Check whether the network sends neighbor reports and transition requests, and whether each client model acts on them.

The fix

  • Run fast transition in mixed mode, advertising both the FT and non-FT key types, when the fleet includes clients that cannot do FT.
  • Put clients that cannot do FT, or that mishandle the extra key types, on their own SSID.
  • Make the mobility domain and key holder configuration consistent across every access point a route crosses.
  • Update client drivers that fail to parse FT key types, after testing them on the route.

Prevent it at design time

  • Inventory every client model's support for 802.11r, 802.11k, and 802.11v by key type before you design the SSID.
  • Keep each vehicle route inside one mobility domain wherever you can.
  • Test roaming across every boundary between access point groups that a vehicle crosses.

Related causes

Terms on this page

About this page

Built from 4 sources: 4 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. "Fast roaming mismatch between client and network." OT Wireless, published October 5, 2026. https://otwireless.com/causes/fast-roam-mismatch/

APA 7

Rutter, B. (2026, October 5). Fast roaming mismatch between client and network. OT Wireless. https://otwireless.com/causes/fast-roam-mismatch/

BibTeX

@misc{rutter2026fastroammismatch,
  author = {Rutter, Ben},
  title = {{Fast roaming mismatch between client and network}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/fast-roam-mismatch/}},
  organization = {OT Wireless},
}