Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)

[Johannes Berg <johannes@sipsolutions.net>]

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