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
