Stop the ‘Sticky Client’ Problem: Configuring 802.11r/k/v in hostapd

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

The Frustration of the ‘Sticky Client’

We’ve all been there: you’re on a critical Zoom call, walking from your desk to a conference room, and the audio suddenly turns into robotic gibberish. Your laptop is still clinging to a weak signal from an AP 50 feet away, ignoring the one directly above your head. It refuses to let go until the connection is effectively dead. Only after five seconds of silence and a dropped call does it finally hop to the closer AP.

This “sticky client” behavior is a classic networking headache. In most setups, the decision to roam rests entirely on your phone or laptop. Without coordination from the infrastructure, roaming is slow and disruptive. If you’re building a Linux-based Wi-Fi environment using hostapd, this is likely the biggest bottleneck you’ll face.

Why Standard Roaming Fails

Standard roaming is a slow-motion disaster for real-time traffic. When a client moves from AP-A to AP-B in a typical WPA2-PSK setup, it triggers a full re-authentication. The process is exhaustive: the device must scan channels, exchange authentication frames, and complete a fresh 4-way handshake to derive encryption keys. If you’re using WPA2-Enterprise, you also have to wait for a RADIUS/EAP exchange.

This entire sequence can take 100ms to 500ms. While that sounds fast, real-time applications like SSH or VoIP begin to stutter the moment latency crosses the 50ms mark. Anything over 200ms feels like a total connection failure. The device is essentially “blind” during this transition because it doesn’t know where the other APs are until it stops transmitting data to scan for them.

The Three-Pronged Fix: 802.11r, 802.11k, and 802.11v

To achieve truly seamless transitions, you need three specific protocols working together. I’ve implemented this stack in high-density office environments, and it consistently brings roam times down to a level where even sensitive VoIP calls don’t drop a single packet.

802.11r (Fast BSS Transition)

802.11r, or Fast Transition (FT), is the heavy lifter. It allows the client and the new AP to handle the 4-way handshake before the client actually switches over. By the time the device breaks its link with AP-A, it has already negotiated keys with AP-B. This cuts the transition time to under 50ms.

802.11k (Radio Resource Management)

802.11k provides the client with a map. Instead of scanning all 40+ possible channels—which drains battery and wastes time—the client requests a “Neighbor Report.” The AP responds with a curated list of nearby access points and their current loads. Now, the client knows exactly which channel to jump to next.

802.11v (BSS Transition Management)

802.11v gives the network a voice. If AP-A notices a client’s signal strength (RSSI) dipping below -75 dBm while AP-B is sitting idle with a -50 dBm signal, it can send a BSS Transition Management Request. It essentially nudges the client, saying, “You’ll have a much better time if you move to AP-B right now.”

Implementing the Configuration in hostapd

Setting this up requires modifying your hostapd.conf. I’ll assume you have a basic working setup already. We will now layer in the parameters for 802.11r, k, and v.

Step 1: Basic 802.11r Configuration

First, we define the Mobility Domain. Every AP that a client can roam between must share the same 4-character hex ID.

# 802.11r Fast BSS Transition
mobility_domain=e642

# Enable FT over-the-air (0) or over-the-DS (1)
ft_over_ds=0

# Unique identifier for this specific AP
nas_identifier=ap-office-01

# Generate R0KH and R1KH locally
ft_psk_generate_local=1

Step 2: Key Management

For 802.11r to work across multiple hardware units, the APs must trust each other. You need to define the R0KH (Remote Key Holder) and R1KH lists so AP-1 can verify a client’s previous handshake with AP-2.

On AP-1 (IP: 192.168.1.10, MAC: aa:bb:cc:dd:ee:01):

# Format: [MAC] [NAS-ID] [32-char Hex Key]
# Local AP entry
r0kh=aa:bb:cc:dd:ee:01 ap-office-01 00112233445566778899aabbccddeeff
r1kh=aa:bb:cc:dd:ee:01 aa:bb:cc:dd:ee:01 00112233445566778899aabbccddeeff

# Remote AP (AP-2) entry
r0kh=aa:bb:cc:dd:ee:02 ap-office-02 00112233445566778899aabbccddeeff
r1kh=aa:bb:cc:dd:ee:02 aa:bb:cc:dd:ee:02 00112233445566778899aabbccddeeff

The 32-character hex key must be identical across every AP in your roaming group.

Step 3: Enabling 802.11k and 802.11v

These settings are straightforward but vital for modern iPhones and Android devices to play along.

# 802.11k: Neighbor and Beacon reports
rrm_neighbor_report=1
rrm_beacon_report=1

# 802.11v: BSS Transition and Sleep Mode
bss_transition=1
wnm_sleep_mode=1

# Nudge the client to roam if the ACK fails at low signal
disassoc_low_ack=1

Step 4: Updating Key Management

You must tell hostapd to advertise FT-enabled suites. Update your wpa_key_mgmt line to include FT-PSK:

wpa_key_mgmt=WPA-PSK FT-PSK

Testing and Verification

Once you’ve restarted hostapd, verify the connection from a client device. If you’re using a Linux laptop, check the status with wpa_cli.

sudo wpa_cli -i wlan0 status

Look for key_mgmt=FT-PSK. If it still says WPA2-PSK, the fast transition didn’t trigger. You can also run a continuous ping to your gateway while walking between APs. In a standard setup, you might see 3-4 dropped packets. With these optimizations, you should see zero drops and a latency spike of no more than 30-50ms during the hop.

Common Pitfalls

I’ve seen many 802.11r deployments fail because of three specific oversights:

  1. Clock Drift: If your APs have different system times, the handshake keys might be rejected as expired. Use NTP to keep them perfectly synced.
  2. L2 Connectivity: Roaming only works if all APs are on the same Layer 2 segment (the same VLAN/bridge). If a client has to grab a new DHCP address after moving, 802.11r is useless.
  3. Driver Limitations: Some budget Wi-Fi cards don’t support FT offloading. Check if your hardware supports NL80211_IFTYPE_AP before pulling your hair out over config files.

Final Thoughts

Fixing Wi-Fi performance isn’t just about boosting transmit power. In fact, turning the power up often makes the “sticky client” problem worse. By implementing 802.11r, k, and v, you give your devices the data they need to make intelligent roaming decisions. It takes some manual effort in hostapd, but the result is a professional-grade wireless experience that stays stable even while you’re on the move.

Share: