Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)

[Johannes Berg <johannes@sipsolutions.net>]

On Sun, 2019-04-14 at 18:12 +0200, Alexander Wetzel wrote:
> > I'll take a look, but a trace-cmd recording would be more interesting
> > than the monitor interface, as it also tells us when what key was
> > installed etc.
> 
> I've just uploaded better captures also including traces to the same 
> location. Everything relevant for this mail is in the folder
> iwlwifi-debug here:
> https://www.awhome.eu/index.php/s/AJJXBLsZmzHdxpX

Great, thanks.

> It looks like we only have a problem when we get frames with the "new" 
> keyID and then again some with the "old" keyID. Of course we also could 
> have multiple problems, too... But in that case I would say let's first 
> look at this one.

This part kinda surprises me.

> The problematic frames are encrypted with the correct "old" key, 
> according to wireshark.
> 
> But on the STA they are scrambled and therefor probably have been 
> decrypted with the - in this case - wrong new key.
> 
> And as it happens there is also a really good looking first suspect why 
> this may have happened:
> According to the STA captures the broken frames came in one A-MPDU which 
> started with keyID 1 and then "appended" the older keyID 0 frames at the 
> end. (The OTA sniffer seems to be miss the A-MPDU details, see the STA 
> capture...)

This doesn't surprise me at all.

> Now it really looks like the mvm cards are trusting the standard and 
> decode all MPDUs within one A-MPDU with the same key while at the same 
> time allow mixing different keyIDs in a-MPDU.

Yes, I'm pretty sure the firmware will only be able to look at the whole
A-MPDU and thus must make a decision based on the first subframe
regarding the key.

> The so far mostly theoretical question how far mac80211 should support 
> the driver (e.g. key ID border signal) or if we want to let the 
> drivers/card handle that would become much more pressing...

Yeah, good point. I guess this really would have to be on the
transmitter though.

> Ideally the card/firmware would be able to detect that and start a new 
> A-MPDU. 

For similar reasons, I don't think it can do this even on TX.

> 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.

> Thanks for the reminder.
> I'll definitely will remember the option, I was not aware that there was 
> a more private way:-)

Just wanted to point it out. I'd agree the risk is minimal since you use
a separate test network anyway.

johannes