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

[Alexander Wetzel <alexander@wetzel-home.de>]

Am 16.04.19 um 21:11 schrieb Johannes Berg:
> 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.
> 

Hm, you are right. There is no grantee that after the first frame with 
the new keyID all frames after that will also use the new keyID when 
using different priority classes, I assume..
But each TID should have a clean cut over, shouldn't it?

But then that would only help us with cards able to control the A-MPDU 
size per TID...
Short of sending a dummy MPDU to each TID from mac80211 as key border 
and the driver waiting for all of them I can't think of anything right 
now. I really hope we can find something better...

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

These should be no problem. The drivers still implement set_key and 
mac80211 will not enable Extended Key ID for them. Enabling Extended Key 
ID with SW crypto for drivers implementing set_key is only possible by 
patching either mac80211 or the driver.

Btw:
That was the main use case I added the mac80211 module parameter 
ieee80211_extended_key_id for. But looks like that was of too little use 
and cut out.

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

I've just greped the drivers, brcmsmac has ampdu_action in its 
implementation of struct ieee80211_ops but no set_key.
So it really looks like SW crypto only to me...

> 
> Anyway, a patch - even if it serves mostly as documentation - would be
> most welcome.

I'll prepare something. Looks really trivial to fix that.

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

Good to know:-)

Alexander