Re: Problems connecting to Fritzbox

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