Obviously in your hostapd config ft_over_ds is switched off.
My config is more complex, as I use radius authentication, but the setup in the ui should be as described here:
1 Like
well i am starting to think maybe my smartphone doesnt support 802.11r
it is huawei nonor 6A
it roams good even if 802.11r is disabled but have the same SSID
Can it be possible that 802.11r simply doesnt work without RADIUS server ?
I don't have one I just use wpa-psk
My setup is without RADIUS, just WPA2-PSK, but I forgot to mention my logs/config are from the master branch (latest development, even newer than 21.0.1), and I haven't tested OpenWrt 19.
1 Like
Thanks , looks like I must try the master branch .
What package u use ?
wpad
wpad-basic ?
wpad-openssl, as I switched from default WolfSSL to OpenSSL.
Here is my relevant diffconfig section in case you want to build your own:
## Wireless
# CONFIG_WPA_WOLFSSL is not set
CONFIG_WPA_MSG_MIN_PRIORITY=4
CONFIG_PACKAGE_hostapd-utils=y
# CONFIG_PACKAGE_wpad-basic-wolfssl is not set
CONFIG_PACKAGE_wpad-openssl=y
# CONFIG_PACKAGE_iw is not set
CONFIG_PACKAGE_iw-full=y
1 Like
I am using 802.11r and it works in my network setup. Thought I'd share some of my experience with you...
I have two routers (of the same brand and model), one being the gateway and other acting as an AP extension. My log (when a client fast transitions to another AP) do not show "FT authentication already completed..." either. But I recall seeing it before, so I have reason to believe this is due to the verbose level. Here is my log (take note of the time):
AP router (transitioning away in this case):
Sat Nov 6 14:02:20 2021 daemon.notice hostapd: wlan0-1: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sat Nov 6 14:02:25 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Gateway (transitioning to in this case):
Sat Nov 6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Sat Nov 6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 6)
Sat Nov 6 14:02:20 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Sat Nov 6 14:02:20 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
And I have a way to really easily test for normal 802.11r operations:
-
On my Android phone, I start KODI, then play a video from local network drive. You can do something like this, or even start copying a file from network drive via SMB etc to your local device - just make sure this is a process that will get interrupted (i.e. not buffered and it won't make attempts to reconnect) if network connection is broken.
-
On the router to which this device is currently connected, go to LUCI then in "status" -> "overview", just go ahead and press the disconnect button for this device
-
If 802.11r is working properly, the other router will pick up the connection right away (assuming it is within coverage), and whatever the process is being run on the device at the moment (video playback, file copy, etc) will continue without interruption.
-
Wait at least 3 minutes (otherwise the original router will just reject the connection attempt), then do the same thing on LUCI of the other router. You should see the connection jumping back to the original router, and since 802.11r is working, the process on the device will once again continue without interruption.
A couple of additional notes:
-
I have not changed wpad at all, just using whatever wpad that comes with the OpenWrt installation. I checked, it is wpad-basic-wolfssl. I am using OpenWrt 21.02.1.
-
My two routers were connected with relayd before. And 802.11r was hit and miss for other devices, and did NOT work for my Android phone at all. I changed to WDS, and this made 802.11r work consistently for all of my devices that support it. And this was back when my routers were running 19.07. With 21.02 the entire connection has been even more stable, fast transitioning included.
(edit: I specifically said KODI above because I saw other apps that will quietly make re-connection attempts then resume playing. I believe VLC acts like that if I recall correctly. My KODI just continues to play the video file with zero pause or interruption, but if 802.11r is disabled, it drops the connection entirely)
4 Likes
You should make log level =1 and you will see 4 steps handshake . No FT.
Your log level doesn't show everything.
I have the same log before I change the level .
My phone works absolutely the same if 802.11r is enabled or not , both AP have the same SSID same encryption and same passwords.
And as you can see on the picture
no disconnect and no FT
Also as you can see the APs have FT
Hmm.. you are right. Changed log level, and my log does show the whole 4-way handshake being done.
Bookmarking this thread. If a solution is found maybe it will help me too...
(I thought all along if there is no connection interruption then it means 802.11r is working)
1 Like
FT is all about make lees the switch time to 50ms , my phone switches for 200ms even with 802.11r off , but if APs have different SSID it is always like 1-5 seconds,
I've tried everything with setting and packagesI think, but I never tried new phones like 2018 and new, main is 2016 I think
1 Like
@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.
