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 13:03, Benson Bear wrote:
> Hi Pablo, thanks for your really prompt reply.   And sorry
> for the spelling error in the Subject header ("Mps" for "Mbps")
> and the horrid line formatting.  (Not used to using short lines
> although that is what I grew up on).
> 
> And... you got it!   The MFP flag is lacking, and googling
> showed me that instead of  messing with wpa_supplicant, I
> can apparently do the same with nmcli:
> 
> nmcli connection modify NAME 802-11-wireless-security.pmf disable
Oh yeah, I didn't check nmcli documentation thoroughly enough to find
that option. Quite easier to implement than going the raw wpa_supplicant
way.
> 
> I tried that and it worked!   Internet speed test back to 600Mbps!
> What a relief!  Thank you very much!
> 
> I will try other testing with just pure Wi-Fi and with all machines
> after I get some sleep.
> 
> Can you tell me why this is likely to have happened?  Surely
> one side or the other is misconfigured?  This misunderstanding
> between them should not be possible within a good specification,
> right?
Given that your client does not have the MFP flag and you can connect
without PMF, that means that your AP advertise MFP Capable (and so is
your client when it is not disabled), and following the association +
4-way handshake, the AP believes it has correctly negotiated MFP but not
your client, so the AP is sending the client encrypted action framed
that are dropped by the client and the client is sending non-encrypted
action frames that are refused by the AP. The easiest way to debug this
would be to capture over the air the auth + assoc + 4-way handshake +
action frame and provide the SSID + the PSK to be able to decrypt
everything and understand who is in the wrong. If it's an issue on the
client side, it is most probably an issue in wpa_supplicant and not in
the kernel.
> 
> (Sadly I think I might have an idea -- it's partly my fault.   The
> mac80211 module was disabling all HT and above because it
> felt it could not meet the BCS criteria laid down by the AP.
> Many people have thought these criteria were way too onerous.
> So I first had very low speeds because of that.  No HT even.
> I applied a patch to the module that ignored these requirements
> and got back to a high connection speed, and HE or VHT
> enabled, and got back a little of the lost speed.   Clearly very
> kludgy but seems a legitimate response to what the patch
> author called "aggressive basic MCS rates". But it may
> have opened up the room for misunderstandings.  I have my
> speed back in practice, but I wonder what the "correct" way
> of fixing this would be -- without the kludgy module patch).
> 
> Thanks again!
>