On Tue, 2019-04-16 at 20:28 +0200, Alexander Wetzel wrote: > They can enable the mode when a key with IEEE80211_KEY_FLAG_NO_AUTO_TX > set This I agree with. > and quiet it again as soon as they get a MPDU using the new KeyID. This isn't true, afaict. You need to be sure that no MPDUs remain using the old key ID, not just that the new key ID showed up. > Since switching back to normal doesn't have to be done immediately a > asyc call from Tx path or even a worker should do the job just fine. Sure. > Btw: > This also means we'll have to update the merged mac80211 Extended Key ID > support: We can only enable it for cards without HW crypto when they do > not set AMPDU_AGGREGATION. With the updated userspace these cards will > start using Extended Key ID with the already merged patches. I was going to say this is fine, but no, of course not ... we shouldn't use different key id in the same A-MPDU. That said, I'd be very surprised if there are any such drivers, except in corner cases (like loading some drivers like ath9k or iwlwifi with swcrypto=1 or so) > Of those only hwsim and brcmsmac seems to support AMPDU and only > brcmsmac relly needs the fix to not lose some packets when rekeying. I can't believe that brcmsmac has no HW crypto support? Anyway, a patch - even if it serves mostly as documentation - would be most welcome. > I assume we still have to wait till the API is in mainline (probably > 5.2) to ask hostapd/wpa_supplicant to merge the patches? No, mac80211-next is (usually?) good enough. johannes
