New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3159 - 802.11r default settings are inappropriate, need to change two default settings #7907
Comments
fsvm88: Adding to this, as I spent the last 2 days debugging why my phone was not doing "fast" (<2m) A->B->A AP transitions (WPA-PSK): some clients do not disassociate/deauth from the old station even after associating to the new one (my OnePlus 5 Android 10.0 phone seems to do this). My final config:
Of course, nasid is '2222' for AP #2. |
jeolives: I've been running 802.11 FT-over-the-air from the beginning when I noticed that the DS option was not performing as well in VoIP calls during a transition to the alternate AP. I can also attest to changing the reassociation_deadline parameter to 20000 has helped considerably.
I'm interested in whether or not this has any trade-offs with the battery life of mobile devices in your setup. I've observed that changing the max_inactivity parameter to 15 generates logspam with the AP-STA-POLL-OK notice. Because of this, I also presume it interrupts device deep sleep due to the empty data frame having to be processed. I will test it myself, but I'd like to also check if you may already have observations to share already. For now, I've changed the default from 300 to 180 (5 mins -> 3 mins) to see if there is a good middle ground. |
bdiggs:
Enabling 802.11r in LuCI auto populates with two default settings that break 802.11r functionality for most devices (though tested extensively on latest Apple iOS devices).
Bug: The current defaults for FT Protocol (FT Over DS) and Reassociation Deadline (1000) break iOS and other devices support for 802.11r.
Solution: Change the current default for FT Protocol to FT over the air and for Reassociation Deadline to 20000.
Support for these new defaults: According to papers from Cisco (https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-6/Enterprise_Best_Practices_for_iOS_devices_and_Mac_computers_on_Cisco_Wireless_LAN.pdf) FT over the air is the method supported by Apple devices and recommended. Furthermore, Cisco's Reassocation Deadline is a default value of 20 seconds (https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html), which would translate to roughly 20000 when used as an OpenWRT setting.
My testing confirms the OpenWRT default values do not work with iOS (FT Over DS is not recognized, and if FT over the air is used with the original Reassocation Deadline of 1000 (roughly 1 second) transition is badly broken as devices will get kicked from their initial AP before associating with the next AP, which removes them from WiFi completely).
For one final piece of support, the 802.11r implementation used with Ubiquity systems is also FT Over the Air: https://community.ui.com/questions/802-11r-question/743b903c-3ad1-4ab6-897f-ebc24269130d I am unsure of their Reassocation Deadline default but I have found the setting of 20000 (which matches Cisco) to work very well in my testing.
The text was updated successfully, but these errors were encountered: