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.
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
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:
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.