@ZebraOnPC
From which wifi analyzer / heatmap app that screenshot with the clear "access port roaming" log is?
1 Like
It is from wifiman ubiquity blue icon with white wifiman on it
2 Likes
Good luck, hope you can find a solution so I can apply it to my setup also.
And thanks for enlightening me with "Wifiman", this is clearly a better way to test wifi roaming. (I guess I am now at a similar situation as yours - switching for 200ms)
1 Like
How do you measure these 200ms ?
I tried out the latency measurement in wifiman while roaming with my Samsung S20 FE.
In our house we have one AP at ground level, and one AP 2 levels above.
The samsung device is sticky and roams only once you reach the level of the other AP, the signal needs to drop to around -75dB or less.
With use of only 2.4 GHZ on both AP, the latency goes up as the signal needs to pass concrete ceilings,... so it goes up from 24ms to about 120ms.
Then the roaming process brings up the ping times to 250ms, sometimes even 400ms. After roaming has happened, ping times go down again...
With 5GHz only the ping times consistently stay at 25ms, even during the roaming process. There is hardly any effect of roaming on ping times visible. Sometimes they might go up to 50ms, but not always.
Question is of course, how frequently the pings are measured. But it looks like the latency of a bad 2.4 ghz signal has a bigger influence than the roaming time.
Maybe this effect is also caused by the Samsung device, as it seems to generally connect to 5ghz faster than to 2.4ghz wifi.
Btw the roaming time with 2.4 ghz was independent of the existency of the 5 ghz wifi. If the target network for roaming is 2.4 ghz, it is relatively slow, if it is 5ghz, it is fast ( also when coming from a 2.4 ghz network).
Btw all roamings happened with FT over DS, I checked the logs no full handshakes happened...
1 Like
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
-
Rekeying Issue - “driver can’t safely do that.” - #18 by dsouza
and -
https://bugs.openwrt.org/index.php?do=details&task_id=3159
.
My Android 11 tablet roamed between
- ipq806x/R7800 with ath10k-ct wifi in 802.11ac mode (VHT160)
- mt7622/RT3200 with mt76 wifi in 802.11ax mode (HE80)
(So the even AC/AX mode difference does not hurt...)
I changed from my normal WPA2/WPA3 mode to the plain WPA2, as some advice suggested that 802.11r does not play well with the WPA2/WPA3 mixed mode.
Using that "Signal mapper" screen from Ubiquiti's Wifiman app helped a lot to notice the roaming actions.
Settings that worked for me:
option log_level '1'
option encryption 'psk2'
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
daemon.debug hostapd: wlan0: STA e0:...:30 WPA: FT authentication already completed - do not start 4-way handshake
Details:
R7800 settings
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option country 'FI'
option log_level '1'
option cell_density '0'
option txpower '21'
option channel '100'
option htmode 'VHT160'
option disabled '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'xxxxxxxx'
option key 'xxxxxxxx'
option wpa_group_rekey '13600'
option ieee80211w '1'
option encryption 'psk2'
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
RT3200 settings
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option cell_density '0'
option country 'FI'
option htmode 'HE80'
option channel '44'
option log_level '1'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option key 'xxxxxxxxx'
option ieee80211w '1'
option ssid 'xxxxxxxx'
option encryption 'psk2'
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
Log extracts
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
15 Likes
I just read about the roaming with the same SSID and password
but i dont see in your config parametrs such us
option nasid 'F85E3C1CDA6A'
option r1_key_holder 'F85E3C1CDA6A'
option pmk_r1_push '1'
and i have Android 7 maybe Android 7 doesn support 802.11r... i cant find
I left all of them empty, to be filled automatically, or to be used at default values.
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
According to this link, the honor 6a does not support 802.11r:
only
IEEE 802.11b
IEEE 802.11g
IEEE 802.11n
are listed
1 Like
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.
1 Like
I agree. Anyhow before again changing the AP settings I would try with a client that is known to work with 802.11r.
I found a site where I can see almost any phone with all parameters ,this one is samsungS20 The site
so ive cheked 4 phones none has 80.2.11r
The site info is not complete. For example the samsung a50 is not listed with 802.11r here, but it works with fast transition.
I would assume that all new phones since at least 2019 are capable of 802.11r.
1 Like
To get worked 802.11r I fulfilled the next steps:
- Used this helper: https://github.com/walidmadkour/OpenWRT-UCI-helper-802.11r to get FT parameters
- 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
- Then installed Wifi badger (or similar soft) on client devices to use the feature https://forum.xda-developers.com/t/app-free-android-4-0-3-wifi-badger-scanning-and-roaming-application-updated-02-25-21.3290389/
Somehow it works.
1 Like
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:
FastTransitionEnabled=1
gRoamIntraBand=1
gNeighborLookupThreshold=0
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.
1 Like
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.
1 Like
Your devices must support 802.11r or it won't work using FT , us I understand only latest phones have this option enabled