Wi-Fi Fast Transition: Verify the Key-Handover Path Before Promising Seamless Roaming

A client moving between two access points with the same SSID has not necessarily used Fast Transition. Before attributing a short interruption to 802.11r, establish the negotiated authentication and key-management suite, the mobility domain, and the actual transition exchange. Then connect that evidence to the application’s interruption budget. A successful reassociation can conceal a slower non-FT fallback.

This procedure targets infrastructure networks using hostapd 2.11 and wpa_supplicant 2.11 as inspectable reference implementations. The production driver, firmware, controller and client integration may offload parts of the exchange or expose different diagnostics. FT-PSK, FT-EAP and FT-SAE are separate qualification rows. This is a key-handover investigation, not a method for choosing RSSI thresholds or deciding when to roam.

Build a capability matrix that includes the selected suite

The 2.11 supplicant configuration names FT-PSK, FT-EAP, FT-EAP-SHA384 and FT-SAE separately. Compilation with CONFIG_IEEE80211R supplies implementation support; it does not prove that an enabled profile, AP advertisement and driver can complete every suite. Record both what is advertised and what the initial association actually selects. wpa_supplicant 2.11, defconfig and wpa_supplicant.conf

Row	Record before the move	Evidence required at the destination
Security suite	Selected FT AKM, cipher and applicable protection policy	Compatible selection; no unexplained non-FT fallback
Mobility domain	Source and destination advertised domain identifiers	Matching intended domain and accepted FT information
Key holders	R0/R1 identities and configured delivery architecture	Destination obtains or derives the required key material
Transition transport	Over-the-air or over-the-DS test case	Trace proves the intended path actually occurred

Do not publish secret key-holder configuration in this matrix. Record configuration versions and whether mappings agree, with sanitized identifiers where needed. The useful artifact is an agreement between components, not a dump of derived keys.

Distinguish domain membership from key availability

In hostapd 2.11, mobility_domain is a two-octet identifier grouping APs within an ESS. The R0 key-holder identity is supplied by nas_identifier; the R1 identity uses r1_key_holder, defaulting to the BSSID. The r0kh and r1kh mappings support the corresponding key-holder communication and authorization. Matching a mobility-domain value alone does not validate those mappings or deliver a usable destination key. hostapd 2.11, hostapd.conf Fast BSS Transition section

First draw the actual key-delivery architecture. Is PMK-R1 pushed, pulled, or locally generated for FT-PSK? The release defaults pmk_r1_push to zero and offers ft_psk_generate_local as a distinct mode. With local FT-PSK generation enabled, the configuration explicitly avoids the usual PMK-R1 push/pull exchanges. Therefore, absence of a backend key-transfer packet is not universally a failure. The expected evidence depends on the configured architecture.

For a push/pull deployment, inspect both sides’ key-holder identifiers, peer addresses, authorization mapping and protected key-transfer configuration. Correlate destination requests or deliveries with the transition attempt. Never fix an unexplained mismatch by broadly trusting every peer or copying production secrets into a support ticket.

Prove which transition transport was used

Over-the-air FT prepares an authentication exchange with the target AP. Over-the-DS FT uses an action exchange through the currently associated AP before the move. The 2.11 supplicant source contains separate paths: wpa_ft_prepare_auth_request() and wpa_ft_start_over_ds(). The normal over-DS entry checks for a target mobility-domain element and matching FT keys. Its force flag is explicitly test-only; bypassing those checks is not a production repair. wpa_supplicant 2.11, src/rsn_supp/wpa_ft.c

Hostapd 2.11 documents ft_over_ds=1 as its default. An AP capability setting does not prove that a particular client used that path. Capture the actual exchange or obtain equivalent driver/controller evidence. When firmware owns the transition, a quiet userspace log may mean missing observability rather than missing FT.

1. Start with a fresh, identified association. Record the selected AKM, source BSSID, mobility domain and credential class. Distinguish the initial authentication from the later transition.
2. Exercise over-the-air independently. In an authorized test setup, constrain the case so its trace demonstrates target authentication and reassociation. Confirm destination key availability using the architecture-specific evidence above.
3. Exercise over-the-DS independently. Identify the action request/response through the current AP, the target identity, and the subsequent move. A final target association without this earlier evidence does not prove over-DS operation.
4. Introduce one controlled mismatch. Use a test-only mobility-domain mismatch, missing authorized key-holder mapping, or unavailable key-delivery path. Record rejection and any non-FT fallback separately. Do not run disruptive cases on a production control network.
5. Repeat after state changes. Restart one AP and repeat each path after caches have changed. Warm success alone can conceal a broken cold key-delivery path.

Interpret the failure at its earliest proven boundary

If the initial association selects a non-FT suite, investigate profile and advertisement compatibility before backend key transfer. If the suite and domain agree but the destination lacks key material, inspect the configured R0/R1 architecture. If key availability is established but the transition exchange is rejected, preserve its status and information-element evidence for implementation analysis. If FT completes yet the application stalls, move the investigation to the post-association data path rather than changing key-holder settings blindly.

For a hypothetical warehouse reader, suppose over-the-air succeeds after an AP restart while over-the-DS fails before reassociation. That is a proposed diagnostic scenario, not a measured result. The discriminating evidence is the action exchange and current-AP forwarding path, followed by destination key availability. Changing RSSI hysteresis would not explain the missing FT exchange.

Use a bounded release claim

A local host test compiled the official 2.11 supplicant with its no-radio driver and inert layer-two stub. A disabled FT-EAP profile parsed successfully. This confirms syntax in that build only; no AP, radio, key transfer or roaming latency was tested.

Approve a specific client/firmware/AP/security-suite combination only after both intended transition paths and failure classifications are captured. Measure application interruption on the target with sequence-tagged traffic and a declared workload. Keep FT protocol success, fallback behavior and application timing as separate results. “Seamless” is defensible only against a stated application budget, not from an 802.11r checkbox.