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
