Hello,

I'm the one banging my head against this issue for quite some time, so
if I can do anything to help here contact me. I'll check the mailing
list from time to time but if you have something I should reply please
add/keep me on CC.

I can now reproduce the issue reliable within minutes on demand and can
also patch the kernels at both ends. (Just started looking at openwrt
and got my first openwrt kernel patch crashing the wlan driver:-)

But now to the topic:

> Right. I think the "new key with old PN" part is probably not really
> happening, although it seems possible. I'd think we should look at the
> receiver first and only then move on to the transmitter if issues
> persist. Having a sniffer capture of the problem with known keys (!)
> would be useful though.

For my understanding that has already be done. And at least for me it
looks like we have hard evidence for that fact.

In the linux bug report you can find an capture extract to verify that -
taken with a remote monitor station - and the PSK's needed to decrypt
the traffic:
https://bugzilla.kernel.org/show_bug.cgi?id=92451
You are probably interested in comment 14.

Maybe a short warning here:
The wireshark patch needed to make sense of these captures was written
by me and on my still sketchy understanding how this all works. But I
see no way how it could mix up keys and all it all only a minor
modification was needed. (It's taking a short cut to decide if it will
add the PSK to the packet by only looking at the key index and not at
the appropriate flags, but hardly relevant here.)

The Key information used to decrypt the packets is added in the same
section as the key index, if you have problems finding it.

This is an older capture and I'll verify that with a new one soon.
I have quite many retransmissions in it and the monitoring station also
missed quite some frames for some incomprehensible reason.

If you wanted the full capture and not the sipped down one from the
kernel bugzilla you can download it here:
https://cal.a.wdyn.eu:65443/index.php/s/UdMpcULG16Lz1Ah

I'll hope I can provide a better one at the weekend.

I have also still some output of my poking around with printk's in the
kernel and attached you an sample from them, see debug-out.txt.gz.
I have not preserved the exact kernel patch for those printk messages,
but attached a version close of it.
(The additional MIC check was a failed experiment of many to get it
working without removing the replay detection mechanism.)

The XXX debug lines are not in the patch, these are just some printk's
at the start of the function with the name printed out to see when the
key was installed.