Yes this is the exact issue I face. I spent an hour today with iPad and verified that FT is working fine. I couldn't recreate the issue though. I tried letting iPad sleep then moving to new AP and starting it up but worked fine. Issue just seems random, hard to recreate and when it happens I see nothing in the logs. 
.
I keep struggling to get Fast Transition working in combination with Radius authentication (11X). Any hints to make this work?
i tryed FT for a year now and i can say it works all u need is a phone that supporters FT but there is a big BUT that almost all phones for some reason decided to switch when the siganl lower then -85Db and this is the problem! U stay far from you AP u connected to for now and it is -76Db it wont switch even if u stay near to other AP in 1 meter! - 76Db is a bad signal.
So there is only one way and it is using kicking for example with DOWN
u cant see FT in logs if u have smartphone that cant do FT and u cant see it if u didnt make loging on level 1
@Lynx did you try to enable 802.11k + 802.11v ? Maybe it will help your wife iPhone.
option ieee80211k '1'
option ieee80211v '1'
Thank you for the suggestion. I haven't tried that. What effect would that have I wonder?
Please try these settings for the iPhone 13 issues, with an otherwise bare-bones configuration:
# Common Options
option rsn_preauth '1'
option ieee80211w '0' #default
option dtim_period '3'
# Encryption Modes
option encryption 'psk2+ccmp'
# WPA Enterprise (despite the name, some of these settings apply to PSK as well)
option wpa_group_rekey '3600'
# BSS transition management frames options (802.11v)
option time_advertisement '2'
option time_zone '<cat /etc/TZ and put whatever is there here>'
option wnm_sleep_mode '1'
option bss_transition '1'
# Fast BSS transition options (802.11r)
option ieee80211r '1'
option mobility_domain '2222'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
# Inactivity timeout options
option disassoc_low_ack '0'
option max_inactivity '300' #default
option skip_inactivity_poll '1'
Ensure NTP is configured and running on your AP.
Do not enable the 802.11k features unless you are using a daemon that configures neighbors for you (DAWN, usteer, etc.). For troubleshooting it is probably best to leave it disabled.
The DTIM 3 is super important. Apple devices do not support DTIM lower than 3. This can cause numerous problems if not set. The reassociation deadline is also important -- the default value is not in line with industry standards.
Do not set or change max_inactivity. After applying configuration, ensure "uapsd_advertisement_enabled=1" appears in /var/run/hostapd-phy*.conf. The station's request to retrieve packets after power save should be sufficient to keep the inactivity timer at bay without the AP having to poll manually.
If this does not work, try turning ft_over_ds back on.
If that doesn't work, disable IPv6 completely on your network, and see if there are any improvements. If the problem goes away with IPv6 disabled, you will need to tweak your router advertisement / DHCPv6 configuration, and that's another whole can of worms.
Some device manufacturers (especially Google) force more aggressive power saving mechanisms in firmware, such that router advertisement packets can end up being ignored. When this happens, IPv6 leases / firewall state can be interrupted. This is technically a violation of the standard, but the work-around is to increase RA interval settings.
Please report back with your findings. The above settings work well for iPhone 13 on my AP.
8 Likes
Been a while. Anyone have success with those settings?
I've just found this thread and I'm wondering too.
Only on this forum there are threads where i.e. bss_transition is said to be set to 0 or others parameters.
I'm wondering if list above is complete (and why 802.11w has to be zero, as some clients may support it so why not "optional"?)
See this post in this thread from @hnyman. These are the configurations that provided the best results for me. However even so there are issues when roaming with Apple devices which does not seamlessly roam with 802.11r enabled.
I’ve discovered that all Android and Apple devices roams very well without 802.11r. So after multiple tentativas I’ve gave up on 802.11r which now is disabled in my 4 OpenWrt access points, and still all devices (including Apple devices) are roaming just fine.
Don't you see huge drops lasting like >100ms then? Enough to disrupt calls, etc.
Without 802.11r you will not have "fast transition". All devices will continue to roam, but the connection will be dropped, then re-established on a new AP.
1 Like
Right now I have "r" (and v, k also) and still fine tune configuration, although I can't get thru 3 AP's with simple ping running on my iPhone withouit seeing some packets dropped. I have more coverage than should, both 5 and 2.4 GHz.
Came here to find possible next tune-options to have it solved and not have WiFi call dropped while moving around house
So I had this thread that I created when I was running into similar issues. Through that I was directed to the settings in this thread.
On my particular iPhone 13, I don't see any dropouts anymore and the signal is constant. However, I have noticed dropouts on a 2019 iPad that is bit frustrating, although it's no where near as often as it was before those settings were introduced.
I definitely would go ahead with the configuration suggested if you're struggling with connection.
Edit, realised I replied to the wrong person
1 Like
Yes, I copied those into the config for my router and noticed a change basically straight away
1 Like
It doesn't have to be zero. I just recommended that for the following reasons:
- The recommended configuration is intended to support as many client devices and roaming features as possible while also being minimal (no additional packages/daemons like DAWN or usteer needed) and keeping problematic options disabled.
- Some client devices and chipset drivers have issues with 802.11w.
- WPA3 requires 802.11w and some client devices, chipset drivers, and possibly certain OpenWRT packages have issues with either/or.
- It works for me.
The intention was for people to try the minimal configuration, see if that gets them to a known-good state, and then to experiment from there. If you find enabling 802.11w and WPA3 works for you, then by all means, use it! Or if you want to introduce DAWN/usteer, try that!
If you have sufficient coverage with 5 GHz, try disabling 2.4 GHz altogether and see if that helps. I've noticed some devices (particularly a Google Pixel 2) will fast-transition from 2.4 to 5 just fine, but not the reverse.
If you need 2.4 GHz support for other devices, try adding a 5-GHz-only SSID and using that for the iPhone instead. You may also consider introducing DAWN/usteer at this point.
Edit to add: I just re-read your post and saw that you mentioned 802.11k being enabled. Have you tried without that? And with it, have you added a package/daemon that will actually prompt/collect the neighbor reports and send them out to the clients. Stock OpenWRT won't do that on its own.
It is possible that some devices may see that 802.11k is enabled, wait for neighbor configuration from the AP, never receive it, and thus roam poorly. I don't have evidence of this in actual implementation (since most of them are closed-source), but it's why I suggested leaving that disabled without an accompanying neighbor report daemon.
1 Like
With this you mean ntpd, or ntpclient?
I guess it's ntpclient to have time exactly synched?
--EDIT:
I started to dig further the time-thing and there's insteresting thread.
I don't know if it's fixed tho, but time seems to be important part of time advertisment
1 Like
I'm having a hell of a time getting devices to smoothly transition from one AP to another. All running OpenWRT 21.02, all with the same SSID and FT configured. FT actually works, but the network doesn't...
Something I learned about hostapd logging: you can turn on debug logging using
uci set wireless.radio0.log_level=1
but restarting hostapd (e.g. service hostapd restart) is not sufficient. I ended up doing service network restart and that finally regenerated the right config file so debug logging turned on.
The problem I'm having is that after my phone (pixel3a) switches to another AP it does not receive anything. It ARPs and pings (I'm running WifiMan signal mapper) and never receives a reply.
Here's what syslog says. Note "802.11: authentication OK (FT)". But 4 seconds after authenticating it disconnects and unless I'm misinterpreting something, that disconnect comes from the device.
Fri Sep 9 11:00:28 2022 daemon.err hostapd: nl80211: kernel reports: key addition failed
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: binding station to interface 'wlan1'
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: authentication OK (FT)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-AUTHENTICATE.indication(58:cb:52:38:a3:bb, FT)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: association OK (aid 2)
Fri Sep 9 11:00:28 2022 daemon.info hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: associated (aid 2)
Fri Sep 9 11:00:28 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 58:cb:52:38:a3:bb
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-REASSOCIATE.indication(58:cb:52:38:a3:bb)
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: binding station to interface 'wlan1'
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: event 6 notification
Fri Sep 9 11:00:28 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: FT authentication already completed - do not start 4
-way handshake
Fri Sep 9 11:00:32 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 58:cb:52:38:a3:bb
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb WPA: event 3 notification
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.1X: unauthorizing port
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb IEEE 802.11: deauthenticated
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-DEAUTHENTICATE.indication(58:cb:52:38:a3:bb, 3
)
Fri Sep 9 11:00:32 2022 daemon.debug hostapd: wlan1: STA 58:cb:52:38:a3:bb MLME: MLME-DELETEKEYS.request(58:cb:52:38:a3:bb)
Fri Sep 9 11:01:00 2022 cron.err crond[1079]: USER root pid 2920 cmd /root/iwinfo_stations.sh
I've done tcpdumps on the AP and on my router and the router receives the ARP requests and replies but the replies never show up at the ethernet port of the AP. I have relatively old D-Link Gbit smart switches and I'm wondering whether they are messing something up. I'm now working my way through port mirroring on the switches to determine where the reply packets end up... I'm using VLANs which adds yet another wrinkle to everything...
If anyone has seen anything like this and has suggestions I'm all ear! I know it's slightly tangential to FT but it's still part of the larger picture of "does fast roaming from one AP to another work?"