802.11r Fast Transition how to understand that FT works?

cotequeiroz · February 18, 2022, 12:28pm

Basically, assuming you're running 21.02 or master and configuring from luci, you just need to turn 802.11r on and disable 'Generate PMK locally'. Leave the r0kh and r1kh empty.

OpenWrt will generate a key for you. Test it with just that to see if it works. The caveat is that it will only use the mobility domain to do so, meaning it will only generate 65536 possible keys, vs 3.403E+38 if you set your own. If you don't set your own mobility domain, then anyone can use the same recipe to compute the key from your SSID, which is not good. I have sent a patch to append the PSK, which should be safe, but it has not been accepted yet.

Then a recommended next step is to setup your own 128-bit key to use for r0kh and r1kh. Running this will generate a random one for you:

dd if=/dev/random bs=16 count=1 2>/dev/null | md5sum | awk '{print $1}'
05ad9451dcaa84f746311694186c29e7

Using 05ad9451dcaa84f746311694186c29e7 as an example, then set:

r0kh to: ff:ff:ff:ff:ff:ff * 05ad9451dcaa84f746311694186c29e7
r1kh to: 00:00:00:00:00:00 00:00:00:00:00:00 05ad9451dcaa84f746311694186c29e7

This exact setup--the key has to be the same--should be used across all your wireless interfaces in all APs doing 802.11r for the same SSID (technically, it's the same mobility domain).

Lynx · February 18, 2022, 2:30pm

Anyone got problems with Apple devices sometimes not playing well with FT (my wife keeps complaining that she has to disable and re-enable WiFi now and then - perhaps after a long period of inactivity, but I am not sure)? I think this is only Apple because I don't see the issue on my android devices.

Is there a solution?

cotequeiroz · February 18, 2022, 3:05pm

I used to have the exact same problem, then out of the blue--or most likely, a config change that I don't remember--they were gone.

I have 5 iPhones (X, XR, 11) regularly in my network of 6 Linksys E8450 running master from dec/2021 (7e89421a7c). I turned 802.11r on January 7, and have been running smoothly ever since.
I use WPA3/SAE, and have 802.11{w,r,k,v} on. DAWN fills up neighbor reports (don't know if that helps with FT). Perhaps ft_psk_generate_local 0 may make a difference. Here's my full config:

config wifi-iface 'Xxx_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Xxx'
        option encryption 'sae'
        option key '***'
        option ieee80211w '2'
        option ieee80211r '1'
        option ft_psk_generate_local '0'
        option ft_over_ds '0'
        option ieee80211k '1'
        option bss_transition '1'
        option ieee80211v '1'
        option disassoc_low_ack '0'

I don't have r0kh or r1kh set because I'm running my patch to compute them from psk. You may want to set them manually.

I also run a legacy SSID with WPA2-PSK, but I don't think I have Apple devices connected to it regularly. It has ft_psk_generate_local '1', and ieee80211w '1', but I can't say if it works or not.

netprince · February 18, 2022, 3:50pm

Thanks for the tips!

Its interesting and frustrating how few of my devices support fast roaming...

My pixel3a will fast roam with PSK2 but not SAE. When I am using SAE the pixel3a locks onto an AP and will not let go until the signal is gone.

Windows 10 does not support 80211r on PSK networks.

My family has various iphones, and I tested one and I think 80211r was working, I need to test it further.

My chromebook will not connect to an SAE network.

My macbook pro m1 from 2020 seems to use 80211r with SAE fine.

So I seem to have it working for apple devices at least.

Lynx · February 18, 2022, 6:16pm

Here is what I have:

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'XXXX'
        option encryption 'psk2'
        option key 'XXXX'
        option wds '1'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option ft_over_ds '0'

@netprince yes my Pixel 3a (what a great device) is very happy with FT on PSK2. Works perfectly all the time. And I have confirmed multiple times FT's throughout the house between 3x RT3200's. I have not tried SAE. It sounds like that is going to break my Pixel 3a or older devices. So stuck between rock and hard place?

I think my wife has an iPhone 13 and that seems to not be working with my PSK2 setup. When I say not working I need to qualify this. When I test it, it works fine. I see the fast transitions as I walk around the house and have confirmed with the right level of logging:

Lynx:

Tue Dec 28 19:12:16 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan1'
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK (FT)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx MLME: MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, FT)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: association OK (aid 1)
Tue Dec 28 19:12:16 2021 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx MLME: MLME-REASSOCIATE.indication(xx:xx:xx:xx:xx:xx)
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: binding station to interface 'wlan1'
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: event 6 notification
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan0: Prune association for xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Tue Dec 28 19:12:16 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: FT authentication already completed - do not start 4-way handshake

The problem is that now and then the iPhone needs to be manually reconnected. It's hard to reproduce.

@hnyman suggested some ideas to get the iPhones to work here:

Could it be something related to inactivity polling:

Certainly I think the issue relates to use following a lengthy period of inactivity. My wife picks up phone from charge and observes no WiFi, and has to manually disable and re-enable.

Hudra · February 18, 2022, 7:15pm

Had the same issues with my iphone xr and these settings (on all ap’s) resolved the issues:

option reassociation_deadline '20000'
option max_inactivity '15'

Read here:

This is my config:

config wifi-iface 'wifinet0'
	option device 'radio0'
	option ssid 'xxx'
	option encryption 'psk2'
	option key ''
	option network 'lan'
	option mode 'ap'
	option ieee80211r '1'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option mobility_domain '1111'
	option reassociation_deadline '20000'
	option max_inactivity '15'

Lynx · February 19, 2022, 3:22am

Thanks. I missed this. What does it do and why 15?

ZebraOnPC · February 19, 2022, 3:25am

i was experementing with dawn and it really works great till client get deauntificated due inactivity (when clent moved from one point to another in 5 -300 secounds ususly it gets deautificated), hostapd does it
so i wonder if you can figure out the parametr that makes deauntification time longer like 30 minuts in my opinion would be grate

Hudra · February 19, 2022, 9:15am

Well actually i just needed a quick solution for my issue and I didn’t really question why it was working .
This is the default value written in the doc:

max_inactivity integer no 300
Station inactivity limit in seconds: If a station does not send anything in ap_max_inactivity seconds, an empty data frame is sent to it in order to verify whether it is still in range. If this frame is not ACKed, the station will be disassociated and then deauthenticated.

Found here:

This was the best explanation I could find:

Going A->B works perfectly, but since the client is never deauth/disassociated from A after the transition, going back to A before max_inactivity kicks in on AP A means the client will not reassociate to A, because A expects the old key and Client uses a new one I suppose (and it's still registered in the kernel, you can observe the infamous "Could not set STA to kernel driver" error until the client decides to re-do the entire handshake properly).
Lowering max_inactivity to 15 seconds allowed me to mostly work around this issue.

github.com/openwrt/openwrt

FS#3159 - 802.11r default settings are inappropriate, need to change two default settings

opened 03:57PM - 07 Jun 20 UTC

openwrt-bot

flyspray

*bdiggs:* Enabling 802.11r in LuCI auto populates with two default settings tha…t break 802.11r functionality for most devices (though tested extensively on latest Apple iOS devices). Bug: The current defaults for FT Protocol (FT Over DS) and Reassociation Deadline (1000) break iOS and other devices support for 802.11r. Solution: Change the current default for FT Protocol to **FT over the air** and for Reassociation Deadline to **20000**. Support for these new defaults: According to papers from Cisco (https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-6/Enterprise_Best_Practices_for_iOS_devices_and_Mac_computers_on_Cisco_Wireless_LAN.pdf) FT over the air is the method supported by Apple devices and recommended. Furthermore, Cisco's Reassocation Deadline is a default value of 20 seconds (https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html), which would translate to roughly 20000 when used as an OpenWRT setting. My testing confirms the OpenWRT default values do not work with iOS (FT Over DS is not recognized, and if FT over the air is used with the original Reassocation Deadline of 1000 (roughly 1 second) transition is badly broken as devices will get kicked from their initial AP before associating with the next AP, which removes them from WiFi completely). For one final piece of support, the 802.11r implementation used with Ubiquity systems is also FT Over the Air: https://community.ui.com/questions/802-11r-question/743b903c-3ad1-4ab6-897f-ebc24269130d I am unsure of their Reassocation Deadline default but I have found the setting of 20000 (which matches Cisco) to work very well in my testing.

So, if I understand correct, with a lower max_inactivity the client get’s deauthed sooner and I guess this helps if you move from A -> B and back to A in a short amount of time.

Lynx · February 19, 2022, 10:22am

Hmm thanks yes. I did read that but find it curious. Does that also apply for FT over air? Since the author writes about FT over DS. It seems mysterious to me. Shouldn't a device deauthenticate as part of transitioning from A to B? Feels like something is broken and this is a band aid.

@hnyman would you be able to shed any light on this?

ZebraOnPC · February 19, 2022, 10:45am

if u use somthing like DAWN for 802.11 k v tecnology and this parametr is what i think it will be good
also why u trying to set up 802.11r? 802.11k and 802.11v also important tecnologys , and help devices to make switchuing disicion faster and DAWN actually use these 2 tecnology

Lynx · March 2, 2022, 11:53am

@Hudra since setting max_inactivity to '15' I have had no more complaints from my wife. This may mean that the iPhone problems have been resolved.

Hudra · March 2, 2022, 3:39pm

That’s good to hear. Happy wife, happy life

I hope it stays this way because a few days after writing you I got some occasional disconnects again. Most of the time I wasn’t even moving from one ap to the other. Just lying on the couch and watching YouTube on my phone. I didn’t have to reconnect manually and after approx. a minute I was always back online. No issues with other devices only with my iPhone xr.
I think there maybe was a bug because I tried every possible wifi setting (that made sense)– I even tried DAWN but noting really made a difference. When I upgraded to the latest snapshot a few days ago my issues seemed to disappear. So in the last 4 days I only had 1 disconnect of this kind. Fingers crossed

InvalidOpcode · March 12, 2022, 5:15pm

I tried this settings too, but xiaomi Mi 9se sometimes keeps freezing wifi-connection connection from time to time.
Fast Roaming works well (only with WPA2, WPA3 cause 4-way re-association) but phone gets in trouble, especially when moving from an AP area to the next while in doze mode.

Here's an extract from phone's log. Anyone spotting something useful?

03-11 18:37:22.875  3282  3282 I MiuiDozeScreenBrightnessController: unregister sensor listener
03-11 18:37:22.875  3282  3282 I MiuiDozeScreenBrightnessController: unregister non ui sensor listener
03-11 18:37:22.875  3282  3282 V DreamService[DozeService]: finish(): mFinished=true
03-11 18:37:22.875  3282  3282 V DreamService[DozeService]: finish(): mFinished=true
03-11 18:37:22.875  3282  3282 V DreamService[DozeService]: onDestroy()
03-11 18:37:22.875  3282  3282 V DreamService[DozeService]: finish(): mFinished=true
03-11 18:37:22.876   841   918 I sensors-hal: activate:147, xiaomi.sensor.aod/37 en=0
03-11 18:37:22.878   841   918 I sensors-hal: activate:158, xiaomi.sensor.aod/37 en=0 completed
03-11 18:37:22.880   841   918 I sensors-hal: activate:147, xiaomi.sensor.nonui/15 en=0
03-11 18:37:22.881   841   918 I sensors-hal: activate:158, xiaomi.sensor.nonui/15 en=0 completed
03-11 18:37:22.882  1488  2294 I chatty  : uid=1000(system) ConnectivitySer expire 64 lines
03-11 18:37:22.883  1290  1290 E wificond: Skip scan ssid for single scan: {}
03-11 18:37:22.883  1290  1290 E wificond: scan() freq: {}
03-11 18:37:22.883  1290  1290 E wificond: scan() ssid: 
03-11 18:37:22.883  1290  1290 E wificond: scan() type: 0, random_mac: 0
03-11 18:37:22.883  2746  3730 D QCNEJ/WlanStaInfoRelay: Received action: android.net.wifi.RSSI_CHANGED
03-11 18:37:22.884 13468 13528 D QCNEJ/WlanStaInfoRelay: Received action: android.net.wifi.RSSI_CHANGED
03-11 18:37:22.885  2771  3079 D MainServiceImplHandler: : handleMessage msg.what = 7
03-11 18:37:22.885  2771  3079 D MainServiceImplHandler: : EVENT_ON_NR_ICON_TYPE
03-11 18:37:22.885  2771  3079 D MainServiceImpl: onNrIconType: Responding back for transaction = null
.....
03-11 18:37:23.079  2771  2771 D DynamicSarService: PhoneStateListener.onDataActivity: direction=3
03-11 18:37:23.079  2771  2771 D DynamicSarService: modem state change, messageType: 128 state: 3
03-11 18:37:23.079  2771  2771 D DynamicSarService: PhoneStateListener.onDataActivity: direction=3
03-11 18:37:23.079  2771  2771 D DynamicSarService: modem state change, messageType: 128 state: 3
......
03-11 18:37:23.608  2771  2771 D DynamicSarService: onSensorChanged distance = 1
03-11 18:37:23.608  2771  2771 D WifiSarController: onStateChanged: type = 3, value = 1
03-11 18:37:23.608  2771  2771 D WifiSarController: setSARLimit: 2
03-11 18:37:23.609 15058 15058 I wpa_supplicant: nl80211: Set SAR mode: enable=2 spec=0 sar_version=1
03-11 18:37:23.619  3204 27671 I chatty  : uid=1002(bluetooth) Binder:3204_7 expire 5 lines
03-11 18:37:23.626  2386 16467 I chatty  : uid=1002(bluetooth) Binder:2386_10 expire 16 lines
03-11 18:37:23.630   816  3085 I chatty  : uid=1002 bluetooth@1.0-s expire 186 lines
....
03-11 18:37:24.459  2605  2605 E DnsResolver: resNetworkResult:android.system.ErrnoException: resNetworkResult failed: ETIMEDOUT (Connection timed out)
03-11 18:37:24.460  2605  2605 E DnsResolver: resNetworkResult:android.system.ErrnoException: resNetworkResult failed: ETIMEDOUT (Connection timed out)
.....
03-11 18:37:26.626  2605 15070 W IpClient.wlan0: [IpReachabilityMonitor] WARN ALERT neighbor went from: NeighborEvent{@175539593,RTM_NEWNEIGH,if=30,192.168.1.1,NUD_PROBE,[cc:2d:21:e8:03:10]} to: NeighborEvent{@175545987,RTM_NEWNEIGH,if=30,192.168.1.1,NUD_FAILED,[null]}
03-11 18:37:26.623  1327  1327 W /system/vendor/bin/ipacm: type=1400 audit(0.0:277824): avc: denied { write } for comm=6E65746C696E6B20736F636B6574 name="ipacm_log_file" dev="tmpfs" ino=29625 scontext=u:r:ipacm:s0 tcontext=u:object_r:ipacm_socket:s0 tclass=sock_file permissive=0
03-11 18:37:26.627  2605 15070 W IpReachabilityMonitor: FAILURE: LOST_PROVISIONING, NeighborEvent{@175545987,RTM_NEWNEIGH,if=30,192.168.1.1,NUD_FAILED,[null]}
03-11 18:37:26.623  1327  1327 W /system/vendor/bin/ipacm: type=1400 audit(0.0:277825): avc: denied { write } for comm=6E65746C696E6B20736F636B6574 name="ipacm_log_file" dev="tmpfs" ino=29625 scontext=u:r:ipacm:s0 tcontext=u:object_r:ipacm_socket:s0 tclass=sock_file permissive=0
03-11 18:37:26.623  1327  1327 W /system/vendor/bin/ipacm: type=1400 audit(0.0:277826): avc: denied { write } for comm=6E65746C696E6B20736F636B6574 name="ipacm_log_file" dev="tmpfs" ino=29625 scontext=u:r:ipacm:s0 tcontext=u:object_r:ipacm_socket:s0 tclass=sock_file permissive=0
03-11 18:37:26.623  1327  1327 W ipacm   : type=1400 audit(0.0:277827): avc: denied { write } for name="ipacm_log_file" dev="tmpfs" ino=29625 scontext=u:r:ipacm:s0 tcontext=u:object_r:ipacm_socket:s0 tclass=sock_file permissive=0
03-11 18:37:26.623  1327  1327 W ipacm   : type=1400 audit(0.0:277828): avc: denied { write } for name="ipacm_log_file" dev="tmpfs" ino=29625 scontext=u:r:ipacm:s0 tcontext=u:object_r:ipacm_socket:s0 tclass=sock_file permissive=0
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error deleting file: Permission denied
03-11 18:37:26.632   855   855 I chatty  : uid=1010 wifi@1.0-servic identical 12 lines
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error deleting file: Permission denied
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error occurred while deleting old tombstone files
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error writing files to flash

Lynx · March 12, 2022, 5:26pm

InvalidOpcode:

03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error deleting file: Permission denied
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error occurred while deleting old tombstone files
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error writing files to flash

No, but this sounds pretty grave to me (especially the second line below):

03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error deleting file: Permission denied
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error occurred while deleting old tombstone files
03-11 18:37:26.632   855   855 E android.hardware.wifi@1.0-service: Error writing files to flash

In case helpful, these are the settings that resulted in no further comments from my wife - happy wife giving a happy life and all:

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'XXXX'
        option encryption 'psk2'
        option key 'XXXX'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option max_inactivity '15'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'XXXX'
        option encryption 'psk2'
        option key 'XXXX'
        option wds '1'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option max_inactivity '15'

InvalidOpcode · March 12, 2022, 5:37pm

I have the same settings

There are a lot, even while happy roaming and connecting...
I'm on a stock stable rom without root or any modding, just for troubleshooting this issue...

Lynx · March 30, 2022, 9:20pm

Still working or disconnects? My wife's iPhone is still periodically needing manual reconnecting. I saw this firsthand myself today.

Hudra · March 31, 2022, 9:30am

No, not really.

It got better but it did not fully eliminate the issues for me. One thing I observed is that the disconnects often happened when I was further away from the AP and the client (Iphone XR) decided to switch to the 2.4 ghz band. Then it often happened that I was still connected to the AP but I had no Internet until I disabled and reenabled Wifi on my phone. Sometimes this didn’t even work.

Maybe this is a driver/hardware issue as it only happened with my 2nd AP (Unifi 6 LR) which uses the same WLAN Hardware (MediaTek MT7622) as your Belkin RT3200 if I remember correctly. Maybe it has issues with band steering?

Lynx · March 31, 2022, 10:24am

@hnyman any ideas?

ACwifidude · March 31, 2022, 12:44pm

The client drives the roam. Before tweaking further with router settings you might be suffering from AP placement or sharing a SSID between two bands with different physics. I’d take a second to make some measurements first.

Apple has a nice write up of what triggers a roam for iOS devices. If you have the same SSID on both bands, 2.4ghz and 5ghz will have different RSSI at distance - so depending on your environment, interference, and AP placement, your device will make the choice to jump. If you don’t like the physical location of where it is jumping to another band or another AP - take some RSSI measurements all throughout your environment to see how each band and each AP is seen by the client throughout your house.

Consider:

more or less transmit power (sometimes less is better)
different SSID for 5ghz and 2.4ghz. It is impossible to create a clean 67dB overlap between APs for both bands simultaneously. Consider setting your faster devices to a 5ghz only SSID and optimizing APs for 5ghz overlap. I found a good spot halfway through my house that I wanted fast clients to hand over. I placed APs high & unobstructed, turned down the transmission power to 20 (both APs RSSI were ~67dB at this midpoint after these changes), and kept iOS on a 5ghz only SSID.
physically changing where heavy items / mirrors / other items are placed that kill wifi…..or changing AP location to optimize for these factors.

Write ups:

MacOS write up has a little more detail (not sure if iOS has the same selection logic but Apple tends to make things similar):