But how did you install this on openwrt ?
It might be possible to run on Openwrt, but in my case not required - I have Kali Linux running on another system - since all I need is to find out what the client supports where the software runs is not important ie this just reports what the client can do based on what the client send to a fake AP setup by this package.
In theory hostapd has all this info, and maybe there is a way to enable full debug and see some of the equivalent details - it took a minute to install this package so for me was the fastest way to check out my clients - all are good for 802.11{k,r,v,w} - those are the letters I was after 
1 Like
To get 802.11r working on RT3200 I followed @hnyman's findings and set:
Worked for me. I guess these should be set as the defaults in OpenWrt since the existing defaults do not work.
To test you can look at associations, connections and disconnections on logread and observe lack of 4-way message on subsequent connections when roaming.
I would also highly recommend the Ubiquiti WiFiman app, which allows you to plot latency and overlays roaming events. You can feel like a proper nerd walking around your whole house peering at your phone as the thrill of fast transition flows through you like lightning.
6 Likes
I assume that you installed luci-app-dawn for 11k and 11v - if not please share how you enabled them.
Yes I used Dawn for 11k and 11v. Unfortunately Dawn still doesn't seem to be stable enough for everyday use. I have since removed it from my setup.
Recently i got new phone on Android 11, set up new device with
wpad-basic 2019-08-08-ca8c2bd2-7 296.7 KB on it and did minimal setting
And everything works
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 MLME: MLME-REASSOCIATE.indication(06:c9:b3:6f:db:49)
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 WPA: event 6 notification
Sat Nov 27 01:58:20 2021 daemon.debug hostapd: wlan0: STA 06:c9:b3:6f:db:49 WPA: FT authentication already completed - do not start 4-way handshake
works the same with Over DS or Over The Air
I have been able to make 802.11r work - it was a long process and would not have been possible without the help of the forum here and Reddit posts - my setup is a bit more complicated as I use multiple tagged vlans and Radius auth for one of the SSID. I hope the following will help people trying to get this going. All this was done using 21.02.1 - I replaced iw with iw-full and use hostapd-wolfssl - as this is a dumb AP wpad is not used - I am not sure if the iw change is required - I need full hostapd as I use Radius auth.
Let me start by saying that the Gui 'automatic' setup just did not work for me - there are many people that say it does, I am am sure it does for many, but I wonder if people test it properly - by far the best method I found for Android is to use the WiFiman app - select Signal Mapper, and walk around - if you see BSSID to BSSID transitions it is working fine. If you see Disconnected to BSSID transition in WiFiman, 11r is NOT working.
If you don't have access to Android, your next best option is to enable level 1 debug for hostapd process and look for the FT string. Again please note you need to verify that the client you are using for testing does support 802.11r - without that you might be wasting your time ( see below how to test your client ).
Here are the steps I took to make my setup work:
- Test my clients for 802.11r support ( used both Android 11 and 12 ) using profiler script
- Obtain BSSID for all the SSID used for roaming on all access points used
- Generate config using helper.py script
- Update /etc/config/wireless and restart with wifi reload command
- Test using WiFiman or enable loglevel 1 for hostapd
-
Testing clients - in my case I used Kali Linux and follow the steps on link - the only problem I run into was that my newer Wifi adapter was not supported - otherwise it does work and can generate fair bit of info - the output is saved in /var/www/html/profiler
-
Obtain BSSID - I have two APs, each with 3 SSID, on both 2.4 and 5Ghz - right now only one SSID is used for roaming ie used by mobile devices - the others are for fixed IOT devices - in my case the wlan0 and wlan1 are assigned - to avoid mistakes with MAC addresses I would recommend to cut&paste. The command I used to quickly find the relation between SSID and BSSID was:
ssh to AP
egrep '^(ssid|bssid|interface|bss)=' /var/run/hostapd-phy*.conf
- Generate config using helper.py (link)- it will create output that can be used with uci or added directly to the wireless config - I used the config method
On any system that can run Python3
cd /tmp
wget https://raw.githubusercontent.com/walidmadkour/OpenWRT-UCI-helper-802.11r/master/helper.py
chmod +x helper.py
./helper.py 0 -ap XX:XX:XX:XX:XX:XX -ap YY:YY:YY:YY:YY:YY -ap ... --format config
- Ssh to your AP and use the output of the above command to update the wireless config - please make sure to match the correct SSID with the helper output - also I needed to add the following options to each SSID used for roaming:
vi /etc/config/wireless
config wifi-iface 'wifinetX'
...
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '0'
wifi reload
- Test - as mentioned before WiFiman was the simplest way to test it as it clearly shows when roaming - you will see BSSID to BSSID transitions under the Signal Mapper button - to get there:
- connect your phone to the SSID used for roaming
- start Wifiman
- select Wireless menu - will display list of all networks
- select your SSID
- you should see a blue button 'Signal Mapper' - if you don't see the button, you have not selected the SSID your phone is connected to.
As with any problem, once you have a working solution it, it is much easier to go back - you can look at removing some things from the config, and even trying the Gui method - I would backup the /etc/config/wireless file - at least the manual method does work and is a good starting point for people that are having difficulty getting 802.11r going - good luck.
9 Likes
@xman Thanks for that. I've been wondering how to test 802.11r with my WRT1900ACS and WAC104.
I have a Pixel 6 and the "automatic" setup. WiFiman is showing BSSID to BSSID transitions without any disconnects.
I did some basic tests, and I need to test more. But I`ve found that Android is fast roaming OK, and iPhone and Windows are not OK.
It is quite possible that the client wifi drivers do not really support 802.11r
I have a suspicion that the FT problems described here can be traced to this behavior described in mac80211:
* The ASSOC test makes sure the driver is ready to
* receive the key. When wpa_supplicant has roamed
* using FT, it attempts to set the key before
* association has completed, this rejects that attempt
* so it will set the key again after association.
*
* TODO: accept the key if we have a station entry and
* add it to the device after the station.
The rejection shows up as:
hostapd: nl80211: kernel reports: key addition failed
The TODO reminder implies that it is not really ideal. Apple devices may not like that while others will play along better.
I assume someone will have to retry to set the key. Hopefully, it won't be the STA. I wonder how much can this slow down "fast transition"? 
3 Likes
I checked my logs and see a fair number of the 'key addition failed' messages - roaming still seems to work OK for Android, but for iOS I had to move it off roaming as it was getting stuck too many times ( had to turn Wifi off-on on the iOS device to make it go).
I used to run dd-wrt, but have not followed that for a while - since they use vendor blobs for many of the drivers I wonder if their support for 802.11r is better or worse compared to Openwrt.
1 Like
I am in exactly the same boat. Android works perfectly, but my wife complains her iPhone and iPad have connection issues and she has to manually reconnect.
Is the only solution to completely disable 802.11r?
@hnyman you managed to get FT to work for many with your suggested settings:
Any thoughts on this key addition failed / iPhone issue? And what we might do to address?
@dsouza I've been reading your excellent posts on this issue. What's the latest? Must we disable 802.11r for iPhones?
Not really. I have no Apple devices to test with.
Somebody with affected devices should debug more closely than "it does not work". Probably add debug statements to the hostapd and mac80211 code, check hostapd mailing lists for relevant discussions etc.
Like cotequeiroz speculates above, it may be a combination of simplification in mac80211 and "smartness" in iOS.
Wow that looks complicated. What's the motivation for filling in all these fields about keys?
Any idea what is the minimum one that makes iPhone work? @hnyman would you be able to hazard a guess?
Some guesses:
- The r0 R1 keys are calculated automatically by default, likely not important.
- Various timings, inactivity etc. might be the important ones...
- (Mobility domain might need to be byte-symmetrical so that implementation in little-endian/big-endian routers. But as your other clients work, I guess that is not the case here.)
- Wpa2/3 mixed mode and/or 802.11w might be problematic. So keep wpa2 and stick to w disabled.
And naturally it might be good to figure out if it is about certain iOS versions.
2 Likes
What is bite simetrical ? Like what ?
1111 -> 1111
1110 -> 0111
Is 1111 in hex definitely symmetrical though?
@hnyman thank you so much for sharing your thoughts here. Working on this now.
1 Like
Two identical bytes, like 1111 or 1313.
There has been discussion that there are differences in hostapd implementations if that is handled as byte string or as hex number.
Various CPUs may store hex number 12345678 either as 12:34:56:78 or as 78:56:34:12
See discussion starting at