FS#3159 - 802.11r default settings are inappropriate, need to change two default settings

[openwrt-bot]

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.

[openwrt-bot]

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 understanding was that at least in FT-over-DS via communication to the old AP, this case should have been covered by hostapd, but it's not.
Going A->B works perfectly, but since the client is never deauth/disassociated from A after the transition, going back to A before max_inactivity kicks in on AP A means the client will not reassociate to A, because A expects the old key and Client uses a new one I suppose (and it's still registered in the kernel, you can observe the infamous "Could not set STA to kernel driver" error until the client decides to re-do the entire handshake properly).
Lowering max_inactivity to 15 seconds allowed me to mostly work around this issue.
My guess it that this case is better-handled in WPA-EAP deployments, where one controller is in charge of the keys and does push/pull to the APs.
max_inactivity of 300 should work well for most users - not that I'm walking in and out of my house rooms every other minute myself - but I guess improving the documentation would save many more users a lot of time (esp. for the WPA-PSK usecase).

My final config:

config wifi-device 'radio0'
option beacon_int '80'
option channel '60'
option country 'XX'
option htmode 'VHT80'
option hwmode '11a'
option legacy_rates '0'
option macaddr 'FF:FF:FF:FF:3c:56'
option txpower '17'
option type 'mac80211'

config wifi-iface 'wlan0'
option bss_transition '1'
option device 'radio0'
option doth '1'
option encryption 'psk2+ccmp'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option ieee80211r '1'
option ieee80211v '1'
option ieee80211w '1'
option key ''
option max_inactivity '15'
option mode 'ap'
option nasid '1111'
option network 'lan'
option pmk_r1_push '1'
option reassociation_deadline '20000'
option ssid 'net-5g'
option wnm_sleep_mode '1'

config wifi-device 'radio1'
option beacon_int '80'
option channel '3'
option country 'XX'
option htmode 'HT20'
option hwmode '11g'
option legacy_rates '0'
option macaddr 'FF:FF:FF:FF:84:eb'
option txpower '17'
option type 'mac80211'

config wifi-iface 'wlan1'
option bss_transition '1'
option device 'radio1'
option doth '1'
option encryption 'psk2+ccmp'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option ieee80211r '1'
option ieee80211v '1'
option ieee80211w '1'
option key ''
option max_inactivity '15'
option mode 'ap'
option nasid '1111'
option network 'lan'
option pmk_r1_push '1'
option reassociation_deadline '20000'
option ssid 'net'
option wnm_sleep_mode '1'

Of course, nasid is '2222' for AP #2.

[openwrt-bot]

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.

Lowering max_inactivity to 15 seconds allowed me to mostly work around this issue.

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.

[taylorkline]

Exciting to have this now the default!