802.11r broken in recent master (NL80211_ATTR_STA_VLAN errors)?

Devices: Netgear R7800, UniFi AP AC Lite

I used to have 802.11r working, but it appears it stopped working recently, maybe because of all the mac80211 backports.

With option ft_over_ds '1' which worked before, I now see these errors in the logs on all 3 devices:

Mon Feb 15 20:08:45 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Mon Feb 15 20:08:45 2021 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=xx:xx:xx:xx:xx:xx ifname=wlan0 vlan_id=0) failed: -2 (No such file or directory)

With option ft_over_ds '0', the error NL80211_ATTR_STA_VLAN is gone but
daemon.err hostapd: nl80211: kernel reports: key addition failed
is still present in the logs.

802.11r does not appear to be working anymore, I enabled hostapd logging and I no longer see FT authentication already completed - do not start 4-way handshake in the logs which I used to confirm it was working. The clients are iPads that used to roam before.

Using WiFi Analyzer on Android, all 3 APs report WPA2-PSK+FT and RSN-PSK+FT so the APs report it as supported at least.

For those who want to try it, here's how I enable hostapd logging:

uci set wireless.radio0.log_level=1
uci set wireless.radio1.log_level=1
uci commit wireless
wifi up

Anyone seeing similar issues? Hopefully we can figure this one out and make sure it works in the upcoming 21.02 stable release.

1 Like

Some related discussion here about "FT over DS" vs "FT over the Air"

FWIW, it seems to be OK now on the latest 21.02 builds with option ft_over_ds '0', the iOS clients started roaming again. With hostapd debugging enabled I'm seeing:

Sat Feb 27 13:46:03 2021 daemon.debug hostapd: wlan0: STA xx IEEE 802.11: authentication OK (FT)
Sat Feb 27 13:46:03 2021 daemon.debug hostapd: wlan0: STA xx MLME: MLME-AUTHENTICATE.indication(xx, FT)
Sat Feb 27 13:46:03 2021 daemon.debug hostapd: wlan0: STA xx WPA: FT authentication already completed - do not start 4-way handshake
1 Like

Thanks for the tip, I'm giving this a try now. I was seeing the same errors and even worse: a few clients refused to (re)connect to wifi after wakeup until I went and clicked 'disconnect' in the UI. Running OpenWrt 21.02-SNAPSHOT r15879-3b6c93298c.

I have a client that sometimes disconnects and does not auto reconnect. It may be a different issue, not sure, hard to track it down. It started recently though with all the changes around hostapd/mac80211.

FWIW, dmesg has lots of these messages:

[628349.322294] ath10k_pci 0000:01:00.0: fetch-ind: failed to lookup txq for peer_id 173 tid 0
[639882.834400] net_ratelimit: 1 callbacks suppressed

I filed this issue, though not sure anyone really looks at these issues, there are so many open ones, overwhelming.

Thanks for the tip!
It looks like 802.11r FT works on WRT1900ACV2(ACS) and WRT1900ACS, but occasionally throws errors !?
I have just put FT-OVER-DS setting to FT-OVER-THE-AIR and my iPad looks getting DHCP address again while roaming...

Edit : not really stable solution, I lost my IP sometimes again !!

The same behaviour here. Does you found a fix. FT over air seems make it better but error messages still appears.

I just turned off 802.11r completely. It doesn't seem to help much to have it on. Only iOS devices and some Android phones seem to use it and even those are not great. I'm surprised that macOS doesn't support it. Plus it doesn't seem to work at all with WPA3. Not worth the trouble and additional issues.

What we really need is good controller software that forces all clients to roam. Something like DAWN but it seems development stalled on it.

My laptops do support it also and it is very nice if you use Wifi Call with Apple. That was the main reason I switched to OpenWRT. :slight_smile: But actually I turned it off also. But would be nice to have it running again.

Which laptops do you have? I have yet to see it work with laptops.

It’s supported with Intel Cards. Owns a Lenovo X1 Yoga 5.

But I am not sure if it is supported with OpenWRT. But anyhow, Apple devices are fine. I have issues with my laptops only. So if 802.11r is not used it should not be the problem... Mhh...

With my Lenovo Yoga x1 it works perfectly together with openwrt 19.07.07, also with our samsung android smart phones. I use 802.11r and wpa2 enterprise.

For me, 802.11r worked perfectly for over a dozen wireless devices from different manufacturers, except one. A specific android phone from a French company would flat out fail to connect to any roaming enabled AP. Hence it's turned off.

I'm running the latest master, and I'm also having issues with 802.11r on a WPA2 network. My Fedora laptop is unable to roam and I get the following message in my router log:

daemon.err hostapd: nl80211: kernel reports: key addition failed

I'll have to run some more tests to confirm that this is due to some bug in OpenWrt and not a bug in my Fedora distribution.

Yeah I've seen that error too. I've given up on 802.11r. I don't really have any problems even on wifi calling if i walk around, maybe some audio artifact but it doesn't drop the call.

Ok, same error happens when the iPad tries to roam so this is an issue with OpenWrt. I'll see if I can get the attention of some developer so we can get this fixed.

I filed a few of these bugs at https://bugs.openwrt.org/ but they don't seem to get any activity except for "me too" comments.

Yeah, that happens =( I'm trying to get hold of someone on IRC.


Same here: Mane router is a r7800 and AP is a c7-v2. I get the same output in my logs.