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?
Handling that on the Tx path would be tricky, but I you are right:
Drivers should be able to handle that as it is on the control path, too.
They can enable the mode when a key with IEEE80211_KEY_FLAG_NO_AUTO_TX
set and quiet it again as soon as they get a MPDU using the new KeyID.
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.
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.
Drivers which should be able to use Extended Key ID with the two merged
patches seem to be:
admtek/adm8211.c
ath/ar5523/ar5523.c
broadcom/b43legacy/main.c
broadcom/brcm80211/brcmsmac/mac80211_if.c
mac80211_hwsim.c
marvell/libertas_tf/main.c
ralink/rt2x00/rt2400pci.c
ralink/rt2x00/rt2500pci.c
realtek/rtl818x/rtl8180/dev.c
realtek/rtl818x/rtl8187/dev.c
zydas/zd1211rw/zd_mac.c
Of those only hwsim and brcmsmac seems to support AMPDU and only
brcmsmac relly needs the fix to not lose some packets when rekeying.
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?
Agree. Or drivers can decide to deny A-MPDU setup when the key has been
installed with IEEE80211_KEY_FLAG_NO_AUTO_TX when they want.
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.
Ok:-)
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?
At the moment I'm planning to get the patches merge ready and posted as
RFC till 5.2 is out. I'm also planing to keep Extended Key ID for Mesh
networks till later, so we can focus on AP/STA.
Alexander
