Does this happen with WPA2/3-PSK as well? Because I certainly have the issue with WPA2/3-EAP. Have currently turned 802.11r off in my production environment.
Yes. Happens also there.
@fodiator Am now up to speed on building OpenWRT myself. How are you getting on with the patch. Can I help in any way, for example with testing?
PS Some advice for anyone also else getting up to speed with OpenWRT build following the openwrt.org Build System guidance in anticipation of @fodiator's patch:
- Use the fastest computer you can - else the process is slow
-
git tagis a step that I don't yet fully understand. It displays a list of available build choices, but isn't clear how one might choose on. "q" gets you past the step and I usegit checkout masterrather than the release version so this seems redundant to me.
Still having to make the final test.
In the meantime I’d be interested to learn if the code above improves your roaming, and - if so - if you see any throughput degradation (I don’t)…
Will take this up and notify you once I got the new patch working.
Sorry for not replying already. Have been fighting the LUA bug in recent days. Thus not making progress with testing the patch.
Snapshot seems now to incorporate mac80211: update to linux 6.1-rc8. Updating my WiFi infra produces daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED [snip MAC addr] auth_alg=ft.
I still get key addition failed, but it seems at last an official fix is coming down the pipe. I'm excited to investigate what the actual code changes might be.
[-updated-]
The pattern as I roam away and back (with buttery fast transitions) is now:
Mon Dec 12 11:57:40 2022 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED [-mac snip-]
Mon Dec 12 11:57:40 2022 daemon.err hostapd: nl80211: kernel reports: key addition failed
Mon Dec 12 11:57:40 2022 daemon.notice hostapd: phy0-ap0: STA-OPMODE-N_SS-CHANGED [-mac snip-] 1
Mon Dec 12 11:57:40 2022 daemon.notice hostapd: phy0-ap0: STA-OPMODE-N_SS-CHANGED [-mac snip-] 2
Mon Dec 12 11:57:40 2022 daemon.info hostapd: phy0-ap0: STA [-mac snip-] IEEE 802.11: associated (aid 1)
Mon Dec 12 11:57:40 2022 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED [-mac snip-] auth_alg=ft
Mon Dec 12 11:57:52 2022 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED [-mac snip-]
Mon Dec 12 11:57:52 2022 daemon.err hostapd: nl80211: kernel reports: key addition failed
Mon Dec 12 11:57:52 2022 daemon.notice hostapd: phy0-ap0: STA-OPMODE-N_SS-CHANGED [-mac snip-] 1
Mon Dec 12 11:57:52 2022 daemon.notice hostapd: phy0-ap0: STA-OPMODE-N_SS-CHANGED [-mac snip-] 2
Mon Dec 12 11:57:52 2022 daemon.info hostapd: phy0-ap0: STA [-mac snip-] IEEE 802.11: associated (aid 1)
Mon Dec 12 11:57:52 2022 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED [-mac snip-] auth_alg=ft
Does anyone know what STA-OPMODE-N_SS-CHANGED means?
Note this is under WPA2+PSK and not yet WPA3+SAE. At least not yet working for me. Guessing the latter still has something to do with 802.11w Protected Management Frames or/& the extra authentication exchange WPA3 involves.
6 Likes
Also, could some savvy person explain why there is still deamon.err [...] key addition failed?
Because:
- reassociation is a multistage process, and
- key exchange happens before re-association, and
- key get’s rejected if not associated, because of (some AP’s) not activating hardware decryption
The existing workaround is to have retry cycles that succeed when the association is established. This may time out.
The patch above accepts the key on first offer, which may suffice. In my case it does not affect throughput.
Hope that clarifies.
3 Likes
Have started a new thread on next steps now that FT is back working. That said, it would still be nice to get rid of key addition failed by getting @fodiator's patch finalised & accepted. And to know what STA-OPMODE-N_SS-CHANGED means, albeit the number of times it appears has reduced in my setup under later snapshots.
1 Like
Hi, Has this patch been upstreamed yet? I have 3 APs(Archer A7 v5, Archer A6) and all of them give the same key addition failed on roaming and it do a full 4 way handshake when it shouldn't.
2 Likes
@ishan Don't think the patch is upstreamed yet. For me it seems it wasn't the root cause of FT not working. I get good roaming behaviour even with key addition failed.
If you don't get 2way then it's not FT.
i am also waiting for this feature in next stable release.
Everything else is set and prepared (FT protocol, domain, PMK, DS,...) for this on my APs (100+). :-E
2 Likes
I have the same experience. Roaming works reasonably well even with this error. Elsewhere on the forum, Some one had specified that while roaming, it should not do full 4 way authentication and that ios devices may act a bit weird but my apple devices have mostly been fine with this.
i hope eventually this is merged. 
1 Like
Same here on multiple MT7621 (xiaomi)
Error gone with latest OpenWRT snapshot. No more 4way-Handshakes 
1 Like
Possible to note the snapshot you using? So we know in the future?
OpenWrt SNAPSHOT r21950-90dbdb4941 / LuCI Master git-23.013.73089-9634086 on Xiaomi Mi Router 4A Gigabit Edition in connection with DAWN (luci-app-dawn, dawn).
While I still see the "key addition failed"-message, there is no more 4way handshake and my clients seem to roam fast.
2 Likes
I guess we wait for v23.0
Is there a date set for stable release ? 
Yup, here, recent snapshot, still have the key error but roaming works, no more 4way handshakes
3 Likes
Anyone tested already if it's mergedd with 23.0.4? Or still not working there?