Just documenting here, that I got the 802.11r functioning after I increased the reassociation_deadline to 20000 (from the default of 1000), based on advice from the discussions at
RT3200:
root@router4:/etc/config# logread -f
Sat Nov 6 15:41:18 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan1'
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: authentication OK (FT)
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 MLME: MLME-AUTHENTICATE.indication(e0:c3:77:ae:0a:30, FT)
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: association OK (aid 1)
Sat Nov 6 15:41:18 2021 daemon.info hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: associated (aid 1)
Sat Nov 6 15:41:18 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED e0:c3:77:ae:0a:30
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 MLME: MLME-REASSOCIATE.indication(e0:c3:77:ae:0a:30)
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan1'
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 WPA: event 6 notification
Sat Nov 6 15:41:18 2021 daemon.debug hostapd: wlan1: STA e0:c3:77:ae:0a:30 WPA: FT authentication already completed - do not start 4-way handshake
R7800:
root@router1:/etc/config# logread -f
Sat Nov 6 15:41:42 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED e0:c3:77:ae:0a:30
Sat Nov 6 15:41:42 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: authentication OK (FT)
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 MLME: MLME-AUTHENTICATE.indication(e0:c3:77:ae:0a:30, FT)
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: association OK (aid 2)
Sat Nov 6 15:41:42 2021 daemon.info hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: associated (aid 2)
Sat Nov 6 15:41:42 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED e0:c3:77:ae:0a:30
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 MLME: MLME-REASSOCIATE.indication(e0:c3:77:ae:0a:30)
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 IEEE 802.11: binding station to interface 'wlan0'
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 WPA: event 6 notification
Sat Nov 6 15:41:42 2021 daemon.debug hostapd: wlan0: STA e0:c3:77:ae:0a:30 WPA: FT authentication already completed - do not start 4-way handshake
I think this picture says that there supposed to be only one router that makes PMK-R1 keys for other AP and for itself , so settings supposed to be different on 1 router and other routers that
not create these keys (at least 1 option)
But maybe it is only with special controllers
Well, we use automatics since the commit below, and all those values get calculated from the SSID etc.
Note that instead of automatics, I explicitly used mobility domain 2222, which is byte-symmetrical in case there is possibly bigendian/littleendian trouble between different routers, like pondered in
Those mentioned b/g/n on the linked site are just the major wifi connectivity generation standards (like the newer ac and ax).
I doubt that the site would list all the minor 802.11? feature letters like k,r,v,w.
But in a a sense you are right, e.g. Samsung is vague and mainly says that most phones work since Android 9 (Pie) onward. In addition to the Android itself, it is about the specific wifi chipset in the phone and its driver's capabilities.
802.11r support in Android 7 sounds questionable. Possibly it is not found in most of the Android 7 phones.
Enabled option ignore "1" in section lan in file /etc/config/dhcp on routers which do not give IP addresses (all routers must be connected through ethernet) to prevent the client getting another IP address
I finally managed to get my 802.11r working for my phone (I suspect it would work even for your Huawei Honor 6A too, provided your phone is rooted):
Mon Nov 15 14:12:30 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 9c:bc:f0:xx:xx:xx
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx IEEE 802.11: binding station to interface 'wlan0'
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx IEEE 802.11: authentication OK (FT)
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx MLME: MLME-AUTHENTICATE.indication(9c:bc:f0:xx:xx:xx, FT)
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx IEEE 802.11: association OK (aid 15)
Mon Nov 15 14:12:30 2021 daemon.info hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx IEEE 802.11: associated (aid 15)
Mon Nov 15 14:12:30 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 9c:bc:f0:xx:xx:xx
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx MLME: MLME-REASSOCIATE.indication(9c:bc:f0:xx:xx:xx)
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx IEEE 802.11: binding station to interface 'wlan0'
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx WPA: event 6 notification
Mon Nov 15 14:12:30 2021 daemon.debug hostapd: wlan0: STA 9c:bc:f0:xx:xx:xx WPA: FT authentication already completed - do not start 4-way handshake
I actually did a lot of things to both my routers and the phone itself, so I am not 100% sure which of those things actually did the trick. Therefore if you want, try the following, but no guarantees.
My Xiaomi phone has this file in the /system/vendor/etc/wifi folder: WCNSS_qcom_cfg.ini . Adding / changing the following parameters in the file very likely made 802.11r work on this phone for me:
Like I said, you need to root your phone first to be able to modify this file. If you want to find out more just send me a PM and I will let you know. (This isn't directly related to OpenWrt)
I also did some tweaks to my router wireless settings, and in the process enabled 802.11k and 802.11v (I guess, since I don't have the tech know-how to really validate if these are actually enabled). Not sure if these changes contributed to my success too.
I assume that you installed luci-app-dawn for 11k and 11v - if not please share how you enabled them.
I am interested in 11r mainly for the FT feature - most of my devices are at fixed locations - I have two APs using vlan connections to the main router - in case one AP goes down I want a fast transition without a connection loss.
Part of my difficulties is that I have Radius enabled ( use certificate based auth for my phones, tablets and laptops ), in addition to 802.11w. When I look at the Radius logs I still see the connections, where I would expect the AP to cache the keys - I plan to do more testing using wpa_supplicant and eapol_test from a Kali install.
As we speak I am playing with a great tool that shows exactly what a device can do Link
There are detailed step by step instructions and I had no problem installing it on Kali - of course one needs a Wifi device that can be put into monitor mode - it would not work with a 2.4/5G TP-Link Archer T4U ver.3 but worked great with an older Ralink RT3070 - here is sample output:
# profiler -i wlan2 -c 11 -s Test --no11ax
- Client MAC: e6:44:c9:a2:1f:98
- OUI manufacturer lookup: Apple (Randomized MAC)
- Frequency band: 2.4 GHz
- Capture channel: 11
---------------------------------------------
802.11k Supported
802.11r Supported
802.11v Supported
802.11w Supported
802.11n Supported (2ss)
802.11ac Not reported*
802.11ax Reporting disabled (--no11ax option used)
Max Power 21 dBm
Supported Channels 1-13**
Number of Channels 13
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
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.