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
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 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
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.
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.