Re: Wi-Fi speeds degrade from 600Mps to 30Mps while using WPA2 security, but not on open network, shortly after ISP firmware upgrade.

[Pablo MARTIN-GOMEZ <pablomg@eskapa.be>]

On 16/04/2026 14:34, Benson Bear wrote:
> On Thu, Apr 16, 2026 at 7:47 AM Pablo MARTIN-GOMEZ
> <pablomg@eskapa.be> wrote:
> 
> 
[...]
> 
> Thanks again.  Sadly it looks like linux (the wpa_supplicant) is in
> the wrong here, just reasoning about it.   I assume the AP always
> offers the option.   It doesn't get a rejection before it even makes
> an offer.   So that means when it offered it when PMF was not
> disabled in the client, the client must have accepted the offer.
> Because we know in the other case, when PMF *is* disabled, that it
> works fine, which must mean the AP received correctly a rejection of
> the offer.  So had the client sent a rejection in the first case,
> like it did in the second, there is no reason the AP would not have
> accepted that rejection.  So the client must have sent an
> acceptance.
You have dig slightly into 802.11 standard to understand the PMF
negotiation. Here is a quick summary:
1. the AP advertise MFP Capable/MFP Required support in its Beacon and
Probe Response frames (RSN element)
2. the STA advertise MFP Capable/MFP Required support to the AP in its
Association request (RSN element)
3. the AP will accept the assoc (regarding PMF) unless the STA or the AP
advertise MFP Required and the other one does not advertise MFP Capable;
if both are MFPC, the PMF is "pre negotiated"
4. in the M2 of the 4-way handshake, the STA resend its RSN element (it
must match the one in the assoc frame)
5. in the M3 of the 4-way handshake, the AP sends the IGTK used to
encrypt the (robust) management frames
6. in the M4 of the 4-way handshake, the STA acks the keys as a whole

The AP has the final say in the negotiation of PMF. If there is a IGTK
in the M3, PMF has been negotiated, if not it is not (the STA must send
the M4 even if it was expecting a IGTK and didn't received it). In the
M4, the STA cannot say "hey, the IGTK is missing?!" or "I cannot used
the IGTK you sent me [as long as the MIC is validated]" or "your M4 has
weird content I cannot parse beside the PTK". The bug you are
encountering is most probably either the AP thinking it has put the IGTK
inside M3 but, in fact, has not or the STA not being able to
extract/parse the IGTK [while the PTK and MIC are both valid].

> 
> Not iron clad, because maybe the AP is just plain crazy.
> 
> But it seems that this craziness would be hard to accomplish, since
> there is nothing to distinguish the two cases from its point of view
> if the client correctly rejects in both of them.
> 
> Unless you can say that, contrary to my initial assumption, the
> client makes the rejection even before the offer is made.
> 
> I was hoping I could go back to Rogers and tell them their AP is
> buggy on this point, but it looks like perhaps not.
> 
> Unless you see some other flaw in the reasoning.  If you don't, I
> will take the issue over to the wpa_supplicant people, if you think
> that is a good idea.
> 
> It does seem weird, though, that the client here would send an
> acceptance and then not carry through with it!
> 
> (Since my own problem is solved I might lose interest, and not be
> able to carry out the over the air examination, something like this
> I have never done... but still we should get it resolved somehow)
>