Daemon.err hostapd: nl80211: kernel reports: key addition failed - is this a problem?


in the other forum categories there are many discussion about the recurring error "daemon.err hostapd: nl80211: kernel reports: key addition failed" that also and nobody seems to know there if this is an error or more or less an info only. Perhaps somebody here of the developers could explain this error what is behind that message in short that everybody knows. That would be really nice and many thanks in advance.

Perhaps it is also linked to which are the only errors in my logs that comes up every day: daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=46:xx:xx:xx:xx) ifname=wlan1 vlan_id=0) failed: -2 (No such file or directory)



I was having the same messages in syslog with fast transition of 2 APs.
and after some fiddling, I found that

option ft_psk_generate_local '0'

seems to eliminate those annoying errors.

Do you know if some other settings has to be applied? During my searches I still found some posts described your suggestion also but the general recommendation is to have this enabled. In Luci the help says that some other parameters are used then. (R0 and R1)

As far as to avoid 'key addition failed', this setting if enough. I don't fill the fields R0 nor R1.

I have a all devices roam fast well, Android and iPhones, iPads except one iPhone6.
after some tests,
option ft_over_ds '0'
is the solution.

I setup everything like described here https://www.reddit.com/r/openwrt/comments/515oea/finally_got_80211r_roaming_working/

With that setting the kernel key addition still fails. Did you checked that fast transition is working fine in the debug logs if nothing is entered in R0 and R1?

why not just try to unset ft_psk_generate_local and look if key addition still fails?

I have tested with 2 phones in VOIP mode and roam from AP1 to AP2 without problems.

Did you checked the debug logs? If I set it like you described FT does not work anymore with my APs. Thats perhaps the reason why the error does not appear in the logs.

I can confirm that changing ft_psk_generate_local '0', without R0/R1 parameters, simply turns fast transition off.
Devices start ordinary 4-way handshake when signal goes low

1 Like

keeping "ft_psk_generate_local '0'" and manually setting list r0kh/r1kh parameters still throws "key addition failed" messages in the log, but FT seems to work better and :crossed_fingers: my android phone stills has connection after multiple roamings between APs.

PS: I had "option ft_over_ds '0'" in both configuration cases

Hi Nils, my sincere apology.

My log level was set to '3' so I did not see that FT was simply turned off like InvalidOpcode said.

After setting the log level to '1', I can now see the 4-way handshake if ft_psk_generate_local=0

So I return to the original ft_psk_generate_local=1 and live with the key addition failed.

Does anybody know where to report this error? Found some OpenWRT GitHub projects for e.g. packages or routing which are also responsive but the official bug tracker does not get any response on this error. Is this hostapd related and is there a place to put this?

Still getting this error with 21.02.2:

Also getting the nl80211: kernel reports: key addition failed" error as above:

hostapd: nl80211: kernel reports: key addition failed
hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=X:X:X:X:X:X ifname=wlan1-1 vlan_id=0) failed: -2 (No such file or directory)
hostapd: wlan1-1: STA X:X:X:X:X:X:X IEEE 802.11: associated (aid 1)

MACs elided. As above I'm unsure whether or not this is an issue.

A minor secondary issue is that the builds of wpad for different platforms seem to contain slightly different capabilities - off hand for a C5 Archer I needed the wpad-openssl/wolfssl package to support "bss_transition" whereas for a EA6350 wpad-basic-openssl supported it.

It seems that nobody knows. There was no explicit answer I could find in the past. :frowning:

So after digging in somewhat to the code I think the VLAN error may be extraneous debug - but the key addition might be an issue.

Some news about the error? Do you know what’s behind it as actually nobody knows what is causing it.

The official issue in GitHub is this one: https://github.com/openwrt/openwrt/issues/9071

No sorry, I haven't had the time to dig into it further. It would probably benefit from the eyes of someone who understands both the wpad code and the wireless code in the kernel that it calls.

Keep updating the snapshot in the hope of defeating this bug. Have tried every recommendation under the sun to get 802.11r FT working again (it worked under 19.07). Anyone got any new ideas?

1 Like

Seems to be working on mi Router 4a Gigabit edition using latest snspshot.

@Double-G Afraid still not for me using today's snapshot (r20062). Tested with both "FT over the DS" & "FT over the Air" and with protected frames (802.11w) On & Off.

Double-checked my /etc/config/wireless settings, which are:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:01/0000:01:00.0/0000:02:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option country 'GB'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '[ssid5]'
        option key '[password]'
        option ieee80211k '1'
        option ieee80211r '1'
        option ieee80211w '1'
        option logger_syslog_level '1'
        option encryption 'psk2'
        option ft_psk_generate_local '1'
        option ft_over_ds '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:0e.0'
        option band '2g'
        option htmode 'HT20'
        option country 'GB'
        option cell_density '0'
        option channel '6'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid '[ssid2]'
        option encryption 'psk2'
        option key '[password]'
        option logger_syslog_level '1'
        option ieee80211w '1'

1 Like

Same here

OpenWrt 21.02.3

tplink_eap225-v3 and mikrotik wap-g-5hact2hnd

Generate PMK locally ON

FT over air or DS - same result
802.11w on or off - same result
(KRACK) countermeasures on or off -same result

it just won't work.