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

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2019-04-15 at 22:09 +0200, Alexander Wetzel wrote:
> Honestly I don't like my own patch for the KeyId border signal, too 
> complex and not intuitive at all. But I wanted to have some code for 
> discussion and then got carried away a bit in what may have been not the 
> right direction.

:-)

> Could we not simply ask (at least) the drivers supporting Extended Key 
> IDs to implement a special for the remote STA invisible A-MPDU "stop" mode?
> In this new mode each A-MPDU would simply be build out of a single MPDU. 
> We then could keep Block-Ack active and we don't have to tell the remote 
> STA anything about that decision. After all a A-MPDU with only one MPDU 
> is allowed...
> We then could tell the driver to switch to this mode when installing the 
> new key and out of it again when we have activated the new key for Tx.
> That should be perfectly fine to run only in the control path and 
> comparable simple to set up, too.

Sounds doable, but I'm still debating if we even should give them a
signal - they have all the information in a sense, and do we have a good
idea of when we can go out of this mode again?

(FWIW, I'd probably call it "suspend" and "resume" or so)

> That also sounds like something all drivers supporting A-MPDU should be 
> able to pull off somehow. (But then I've never even looked at more than 
> ath9k and iwlwifi so far for A-MPDU, and at those not close, yet.)
> Do you see any problems with that solution and/or a better idea?

It ought to be possible, or if not then the device just can't support
extended key ID?

> Also would you prefer we first sort out the A-MPDU issue prior I adding 
> test cases to the hostapd/wpa_supplicant or the other way round?

I think adding the code to hostapd/wpa_s is fine - right now we're
obviously OK since we have no drivers using extended key ID that use
hardware crypto, and if we have software crypto there's no problem
either way, even if A-MPDUs are built (which is probably not the case
for any such drivers anyway.)

In a sense I'd prefer getting the necessary bits and pieces elsewhere in
the stack upstream first since that's a prerequisite for anyone
else being able to easily work on this, and that's something we need for
drivers to pick it up.

johannes