From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
Date: Mon, 15 Apr 2019 22:09:25 +0200 [thread overview]
Message-ID: <577d4307-27ca-c5f5-8814-bbef515559e3@wetzel-home.de> (raw)
In-Reply-To: <84694a97bf884985afd49d93e28b309a92801916.camel@sipsolutions.net>
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
next prev parent reply other threads:[~2019-04-15 23:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52 ` Johannes Berg
2019-02-17 19:19 ` Alexander Wetzel
2019-02-22 8:30 ` Johannes Berg
2019-02-22 23:04 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06 ` Johannes Berg
2019-02-19 20:58 ` Alexander Wetzel
2019-02-21 19:47 ` Alexander Wetzel
2019-02-22 8:41 ` Johannes Berg
2019-02-23 21:02 ` Alexander Wetzel
2019-03-01 20:43 ` Alexander Wetzel
2019-02-23 17:26 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09 ` Johannes Berg
2019-02-21 20:07 ` Alexander Wetzel
2019-02-22 8:53 ` Johannes Berg
2019-02-23 22:50 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50 ` Johannes Berg
2019-02-21 21:20 ` Alexander Wetzel
2019-02-22 8:51 ` Johannes Berg
2019-02-23 21:47 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52 ` Johannes Berg
2019-02-22 20:50 ` Alexander Wetzel
2019-02-22 21:06 ` Johannes Berg
2019-02-24 13:04 ` Alexander Wetzel
2019-04-08 20:10 ` Johannes Berg
2019-04-10 20:46 ` Alexander Wetzel
2019-04-12 9:51 ` Johannes Berg
2019-04-14 16:12 ` Alexander Wetzel
2019-04-15 8:44 ` Johannes Berg
2019-04-15 20:09 ` Alexander Wetzel [this message]
2019-04-16 9:31 ` Johannes Berg
2019-04-16 18:28 ` Alexander Wetzel
2019-04-16 19:11 ` Johannes Berg
2019-04-16 21:32 ` Alexander Wetzel
2019-04-12 11:19 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54 ` Johannes Berg
2019-02-22 21:15 ` Alexander Wetzel
2019-02-22 21:20 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05 ` Kalle Valo
2019-02-13 23:15 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44 ` Alexander Wetzel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=577d4307-27ca-c5f5-8814-bbef515559e3@wetzel-home.de \
--to=alexander@wetzel-home.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).