in the last week I tested my laptop using a Ralink wlan stick instead the internal
intel wifi. I never had a problem. This could mean, that the intel driver was the
reason for the problems.
Did you also check the logs that you are no longer rekeying the PTK
immediately after the connect? You only see one "WPA: Key negotiation
completed with ..." when you resume?
However, the Ralink has only 2.4 GHz and the problem only occured with 5 GHz. So
it could also be connected to 5 GHz. I think at the moment there is no way for me
to find out if it is related to 5GHz (and caused by the AP) or it is related to intel
wifi.
I already contacted AVM (the maker of the router), but they had not much interest in
checking this in detail. So I dont think it makes sense to contact them again. Do you think
it makes sense to contact the developer of the intel driver?
They also will very likely need captures or a way to reproduce the
issue. You can of course try but without a capture I'm pessimistic.
The simple workaround still would be to verify that commit 84877f253
("wpa_supplicant: Do not try to detect PSK mismatch during PTK
rekeying") works around the issue and then open a ticket with your
distribution, asking to include that patch. (Should be comparable simple
to install wpa_supplicant from the source dep and apply the patch while
doing so.)
The commit is really simple and I would see a good chance to get it
added as a fix in a stable Linux distribution when you can proof it works.
Now when you really want to get down to the root of the issue you have
to capture the frames on the air.
One good looking sample telling you how to get your card into monitor
mode seems to be e.g. here: https://miloserdov.org/?p=126.
There are of course countless variants how to get OTA captures done,
here just one:
0) Change the PSK of your AP to something you are willing to share
1) Get a dedicated sniffer system ready. Using a USB stick to boot and
save the data is fine. The system should have a card supported by
iwlwifi and is ideally the same or a e for you:newer/bigger version of
the one in the system we want to debug. But as long as the card supports
monitor mode and is able to correctly capture the exchanged frames you
can use it.
2) Make sure nothing on the sniffer interferes with the wlan card. Stop
the NetworkManager, wpa_supplicant and whatever else may try to use the
card.
3) Get the card in the sniffer into monitor mode and set the channel
your AP is using. Verify you get packets when you use the WLAN with
another system nearby.
3) Capture to a file, either with wireshark/tshark or simply with
tcpdump. I would make sure to capture full packages and keep the sniffer
in the vicinity of the problematic notebook, so it sees the same frames
as the problematic station.
4) Reproduce the issue and stop the capture again
5) Examine the capture or send the capture to someone who can.
Be aware that the capture - when done correctly - allows to brute force
the PSK. And depending how exactly the second handshake looks - it
should be already encrypted - the persons you share the file with may
need the PSK to finalize the investigation.
Also be sure there is nothing sensitive in the capture.
As a workaround I disabled the 5 GHz MAC on my laptop, so I dont have a problem anymore.
You can reproduce the issue wen you disable the 2.4 GHz band on your AP?
If somehow both bands are involved - should be impossible - you will
need two sniffer (cards).
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
