Thanks @fodiator, I'm definitely interested. Not only in a release equivalent image, but also in gaining some of the knowledge you have in order to get this far. Please share the TODO in the cfg.c file?
It seems to me, the challenge of OpenWRT is understanding where each and every component comes from. Why is this not already sorted in the upstream Linux components that OpenWRT relies on?
/*
* The ASSOC test makes sure the driver is ready to
* receive the key. When wpa_supplicant has roamed
* using FT, it attempts to set the key before
* association has completed, this rejects that attempt
* so it will set the key again after association.
*
* TODO: accept the key if we have a station entry and
* add it to the device after the station.
*/
I've included patch 100-allow_key_without_assoc.patch under
[buildroot]/openwrt/package/kernel/mac80211/patches/subsys
patch content
Used to remove FT key addition failed error on Archer C7 v2
Index: backports-5.15.58-1/net/mac80211/cfg.c
===================================================================
--- backports-5.15.58-1.orig/net/mac80211/cfg.c
+++ backports-5.15.58-1/net/mac80211/cfg.c
@@ -466,11 +466,15 @@ static int ieee80211_add_key(struct wiph
* TODO: accept the key if we have a station entry and
* add it to the device after the station.
*/
- if (!sta || !test_sta_flag(sta, WLAN_STA_ASSOC)) {
+ if (!sta) {
+ sdata_info(sdata, "mwv1 - no sta\n");
ieee80211_key_free_unused(key);
err = -ENOENT;
goto out_unlock;
}
+ if (!test_sta_flag(sta, WLAN_STA_ASSOC)) {
+ sdata_info(sdata, "mwv2 - no sta assoc\n");
+ }
}
switch (sdata->vif.type) {
This will automatically sourced in when (re)-building source.
Also, now have my ath10k driver ftrace enabled to increase my understanding on how to follow the TODO properly.
I'd be happy to supply a patch file, it's code-wise trivial .
Not sure if this will be accepted as a patch for main release, as it may have the side effect of non-hardware decryption.
For what it's worth, I am tracing the hostapd-mac80211 interplay. It's clear that there is provision for fail-retry settings (depending on ASSOC state), which I need to have a closer look at... Will update here once I understand this better.
---- update ----
the patch above removes the need for the retry cycle in my 802.1x + VLAN setup.
@fodiator understand that it might take longer to get this to a patch that will be accepted.
Meantime, how might we replicate what you have done to get it onto our own setups? Some pointers on where to get going would be helpful. Is it sufficient to follow the Developer Guide on the Wiki?
Any thoughts as to why this hasn't been corrected some time ago already?
@andybjackson building the patch should be fairly straightforward.
Assuming your build environment is set up as per Wiki, you can build the release equivalent as described here:
If you copy the patch content from above
and place it in [buildroot]/openwrt/package/kernel/mac80211/patches/subsys
and run make world you should get the sysupgrade.bin under [buildroot]/bin/targets/[path to your device]
You can confirm the patch is part of your build strings [buildroot]/[yourtarget]/[yourlinux]/backports-5.15.58-1/net/mac80211/mac80211.ko | grep mwv .
In the meantime I am still looking to improve the solution by adding the STA to the driver as per the note above. I have been able to get insight into the hostapd code. Hoping to have an implementation within a few weeks.
The reason this code was 'corrected' seems to be - according to a comment - about hardware decryption not being active when the key is added without being associated on some systems.
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.
@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 tag is 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 use git checkout master rather than the release version so this seems redundant to me.
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:
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.
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.
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.
@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.
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