Subject: Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
References: <20190210210620.31181-1-alexander@wetzel-home.de>
 <20190210210620.31181-8-alexander@wetzel-home.de>
 <1a3b6e515c73a2c185e8dad84ab2ebfd8982a6ce.camel@sipsolutions.net>
 <e84c30de-28d6-7d1b-0fa3-d1ca466e257b@wetzel-home.de>
 <69e6577f90d99289acaa9853fe236e6f15f9e774.camel@sipsolutions.net>
 <14c9d8f7-7cf6-d7e1-a1c0-9f1a10920d4e@wetzel-home.de>
 <ed6e95dad39ef0ac98c62e3acd3f78fd7b3a6d2b.camel@sipsolutions.net>
 <185ea9a2-f3c6-04a5-000b-44191da5a0ee@wetzel-home.de>
 <0de9d60ffef574b34e9a76ad2cea68fab49aac0f.camel@sipsolutions.net>
 <45ae97d6-3357-64ac-0a40-9ae3ea4a8ed2@wetzel-home.de>
 <84694a97bf884985afd49d93e28b309a92801916.camel@sipsolutions.net>
From:   Alexander Wetzel <alexander@wetzel-home.de>
Message-ID: <577d4307-27ca-c5f5-8814-bbef515559e3@wetzel-home.de>
Date:   Mon, 15 Apr 2019 22:09:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <84694a97bf884985afd49d93e28b309a92801916.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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