A few months ago, I switched my network to WPA3-Enterprise with freeradius3 due to a stupid bank app that insists that WPA3-SAE is not secure. In the process, I lost FT roaming between my main router and the WDS repeater.
The radio config is:
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 country 'PH'
option cell_density '2'
option local_pwr_constraint '0'
option he_bss_color '53'
option log_level '1'
option htmode 'HE80'
option channel 'auto'
option channels '132 116 100'
The interface config (with all passwords and keys replaced with dummy values) is:
option device 'radio1'
option mode 'ap'
option ssid 'ENT'
option encryption 'wpa3+ccmp'
option auth_server '192.168.10.1'
option auth_secret 'dummypassword'
option acct_server '192.168.10.1'
option acct_secret 'dummypassword'
option ieee80211k '1'
option wnm_sleep_mode '1'
option wnm_sleep_mode_no_keys '1'
option bss_transition '1'
option network 'lan'
option ieee80211r '1'
option reassociation_deadline '20000'
option ft_over_ds '0'
list r0kh 'ff:ff:ff:ff:ff:ff,*,33333333333333333333333333333333'
list r1kh '00:00:00:00:00:00,00:00:00:00:00:00,33333333333333333333333333333333'
The actual checking of WiFi usernames & passwords is done by the RADIUS daemon, as always with WPA3-Enterprise. The guide is here: https://openwrt.org/docs/guide-user/network/wifi/freeradius
The error message in my Arch Linux laptop logs was:
FT: FTE indicated that AP uses RSNXE, but RSNXE was not included in Beacon/Probe Response frames
Result: an immediate disconnection initiated by the laptop after a roaming attempt, with reason 13=INVALID_IE.
Well, today I debugged this and can share the workaround.
According to Wireshark, the RSN Extension Element (RSNXE, with tag f4) was indeed missing in beacons and probe responses of this AP. As one can see from the wpa_supplicant source, the element is not emitted if there are no supported extended RSN capabilities - which is indeed the case. For SAE, there is no such problem because the AP supports SAE Hash-To-Element, and this needs a bit in the RSN Extension element, which then causes it to be emitted.
So, we need to either ensure that FTE does not indicate that the AP uses RSNXE or add some dummy RSNXE. I don't know how to achieve the first outcome, so I chose the second way.
The easiest way to add the RSN Extension Element that I found is to claim that the AP supports Secure LTF. I don't know what this means or what the consequences are, but at least it can be enabled through a configuration file. This is the line that I added to the wireless configuration:
config wifi-device 'radio1'
...
list hostapd_options 'driver_params="secure_ltf=1"'
After this, FT works with WPA3-Enterprise.
Where should I report this bug - to OpenWrt or to WPA-Supplicant/Hostapd authors?
Any other thoughts?
P.S. There were a lot of recent commits in WPA-Supplicant main branch regarding the omission of RSNXE from Reassociation Responses. Maybe something needs to be backported?