Message-ID: <8a0b0cb563f511be74ccb9a7e491847c87aacc2b.camel@sipsolutions.net>
Subject: Re: [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Alexander Wetzel <alexander@wetzel-home.de>
Cc:     linux-wireless@vger.kernel.org
Date:   Fri, 22 Feb 2019 22:20:33 +0100
In-Reply-To: <4bd73bd3-9027-4689-54e7-7c082eefa327@wetzel-home.de>
References: <20190210210620.31181-1-alexander@wetzel-home.de>
         <20190210210620.31181-9-alexander@wetzel-home.de>
         <63fecadcf3f38f24b547143d9d53b3454adc417a.camel@sipsolutions.net>
         <4bd73bd3-9027-4689-54e7-7c082eefa327@wetzel-home.de>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Fri, 2019-02-22 at 22:15 +0100, Alexander Wetzel wrote:

> I hoped that the HW would already enforce the key border. 

I don't think so.

> But ok: The 
> cards will still be able to use NATIVE mode. Only now the driver will 
> have to request to disable Tx aggregation when finding a key border. 

It doesn't really have to even completely disable it, it'd just have to
send and LQ_CMD with agg_params.agg_frame_cnt_limit = 1, temporarily,
until the relevant frames were transmitted (this is a global config, so
it'd have to track the key border on each TID, but that's not _too_
hard).

> Since Tx aggregation is disabled per default anyhow many users will not 
> even see a difference.

Good point, I forgot all about that.

> (Off topic here, but I suspect the not reproducible problems leading to 
> change the Tx aggregation default to off could also have been ptk0 rekey 
> freezes. In that case we could now allow it again. But I've not found 
> raw error reports and guess it's not worth the efforts/risks to change 
> the default again.)

I wouldn't be so sure - PTK rekeying should still be a pretty uncommon
configuration. But I also don't recall the exact decision making going
into this.

johannes