Am 15.04.19 um 10:44 schrieb Johannes Berg:
But for my understanding the driver could also set A-MPDU to
only one frame, forcing the firmware to flush all A-MPDUs under
construction and then set it back to the normal value. (Or that is how
I've planned to test that in that way with your tips in the past and
what's documented of the mvm/dvm firmware API.)
It's probably getting more complicated with newer versions of the API,
but yes, I guess it should be doable to suspend aggregation.
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.
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?
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?
Looks like I'll have some time at Easter to (start) looking into one or
the other.
I'm currently trending to the A-MPDU issue, as it's the more fundamental
of the two immediate topics. (And the captures are pretty clear, this
explains so far every corrupted packet captured.)
Regards,
Alexander
