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

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

[Benson Bear]

Hi folks, I've never posted here before, don't know much about wireless, but
am having a big problem I have been trying to solve for a week. I've been
googling and ai chatting non-stop but finally after reading the info
page about the
list figured it would probably be acceptable to send this message.

BRIEFEST SUMMARY: There was a firmware update in Rogers's (Canada) XB7 Gateway,
and subsequently my Wi-Fi transfer speeds degraded badly on all three
Linux notebooks I have. Fully up to date notebooks, running Fedora 43 and
42 with most recent kernel 6.19.11. Two different NICs: RTL8852BE and Intel
7265 (rev 59). Wired machines and phones are unaffected.

The machines all connect with high transfer rates of around
800-1000Mbs on the 5G band,
with an 80Mhz wide channnel, and MCS level ranging from 7 to 11 (HE and VHT).

Transfer speeds using WPA2 security have dropped in the one case (RTL)
from 600Mbps to
about 30Mbps. (Using internet speed test but iperf3 gives similar). The other
cases are similar.

BUT the transfer using no network security is still what it used to
be! It is simply
the enabling of WPA2 that brings them to their knees.

So it seems to be a problem related to WPA2, and at a lower level in the
stack of modules, since it happens on two different NICs?

I suspected for a long time that it was a firmware bug in the gateway, but
now I am starting to wonder. I have no solid evidence of that except that
Windows works fine on the same gateway and the same machine.

All three machines work well on another network I have occasional access
to, and have worked fine on this network until about a week ago.

I have ordered another router that I hope I can use to solve the
immediate practical problem, but I would really like to figure out
what is going on and contribute what I can to fixing it, even if only
by being sent out to gather potentially useful data.

Thank you.

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]

Hello,
On 16/04/2026 10:47, Benson Bear wrote:
> Hi folks, I've never posted here before, don't know much about wireless, but
> am having a big problem I have been trying to solve for a week. I've been
> googling and ai chatting non-stop but finally after reading the info
> page about the
> list figured it would probably be acceptable to send this message.
> 
> BRIEFEST SUMMARY: There was a firmware update in Rogers's (Canada) XB7 Gateway,
> and subsequently my Wi-Fi transfer speeds degraded badly on all three
> Linux notebooks I have. Fully up to date notebooks, running Fedora 43 and
> 42 with most recent kernel 6.19.11. Two different NICs: RTL8852BE and Intel
> 7265 (rev 59). Wired machines and phones are unaffected.
> 
> The machines all connect with high transfer rates of around
> 800-1000Mbs on the 5G band,
> with an 80Mhz wide channnel, and MCS level ranging from 7 to 11 (HE and VHT).
> 
> Transfer speeds using WPA2 security have dropped in the one case (RTL)
> from 600Mbps to
> about 30Mbps. (Using internet speed test but iperf3 gives similar). The other
> cases are similar.
When traffic is capped around 30-50Mbps, the usual suspect is
aggregation not being setup.
> 
> BUT the transfer using no network security is still what it used to
> be! It is simply
> the enabling of WPA2 that brings them to their knees.
If I had to guess, this is an issue with PMF. Either the STA or the AP
considers PMF is activated and the other one not; so the action frames
that set up a BA session are dropped.

Check
`/sys/kernel/debug/ieee80211/phy<n>/netdev\:<devname>/stations/<bssid>/flags`
on your notebooks if there is `MFP` in the flags
> 
> So it seems to be a problem related to WPA2, and at a lower level in the
> stack of modules, since it happens on two different NICs?
You can try a few things:
- build a master wpa_supplicant from source and replace the Fedora's
binaries
- use a raw wpa_supplicant connection and set ieee80211w=0 in the config
file
- switch the backend of NetworkManager to iwd
- update the security to WPA3
> 
> I suspected for a long time that it was a firmware bug in the gateway, but
> now I am starting to wonder. I have no solid evidence of that except that
> Windows works fine on the same gateway and the same machine.
> 
> All three machines work well on another network I have occasional access
> to, and have worked fine on this network until about a week ago.
> 
> I have ordered another router that I hope I can use to solve the
> immediate practical problem, but I would really like to figure out
> what is going on and contribute what I can to fixing it, even if only
> by being sent out to gather potentially useful data.
> 
> Thank you.
> 

Pablo MG

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

[Benson Bear]

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

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?

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

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

[Johannes Berg]

On Thu, 2026-04-16 at 07:03 -0400, Benson Bear wrote:
> 
> (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).

I think what you're referring to here might be this?

https://lore.kernel.org/linux-wireless/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me/

johannes

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

[Benson Bear]

On Thu, Apr 16, 2026 at 7:09 AM Johannes Berg <johannes@sipsolutions.net> wrote:

> I think what you're referring to here might be this?

> https://lore.kernel.org/linux-wireless/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me/

Absolutely yes that is the issue, but the patch I found was different.

As far as I can tell that patch did not determine any specific
conditions under which the check could be bypassed, and this
one does.   And, I assume, it does so correctly?

 So the "correct" way forward that I was asking about has already
been found?  Excellent.

I will apply this patch myself and determine that it does the
job for me just as the other one did.

Here by the way is the one I used, from out in the wild:

https://github.com/WoodyWoodster/mac80211-mcs-patch

So I had two issues with the Rogers XB7 firmware.  They
seem now to be unrelated?   I think plausibly mac80211
could be said to have a bug in it, on the BCS issue, but
what about the issue I originally asked about?

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]

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

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

[Benson Bear]

On Thu, Apr 16, 2026 at 7:47 AM Pablo MARTIN-GOMEZ <pablomg@eskapa.be> wrote:


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

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.

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)

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

[Johannes Berg]

On Thu, 2026-04-16 at 08:34 -0400, Benson Bear 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.

Doesn't mean they both negotiated the use correctly, or even encrypted
the frames correctly. Could even be that they both agreed on PMF, but
then the AP sent unencrypted AddBA request (or response, depending on
the direction) and the client dropped it, or any other weird things.

> Not iron clad, because maybe the AP is just plain crazy.

My bet would be on that but we'd have to see a sniffer capture. But in 
general, we definitely know that PMF works with Linux/wpa_s and WiFi7
requires it, etc.

johannes

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]

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

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

[Benson Bear]

On Thu, Apr 16, 2026 at 10:03 AM Pablo MARTIN-GOMEZ <pablomg@eskapa.be> wrote:

> You have dig slightly into 802.11 standard to understand the PMF
> negotiation. Here is a quick summary:

Thanks very much for that.  It shows me how the STA can be put
into a bad place by errant AP behavior.   I will try to get the
information that will diagnose this.

But I am having some trouble setting up the monitor mode on one
machine to grab the packets produced by the AP and the
other machine.  I can probably figure it out and once I get that I will
save in a file and forward this  file after I try to look at it myself also.
I have to work at this in little pieces so it may take a while.

On 2026-04-16 09:58, Johannes Berg wrote:

> > Not iron clad, because maybe the AP is just plain crazy.
>
> My bet would be on that but we'd have to see a sniffer capture. But in
> general, we definitely know that PMF works with Linux/wpa_s and WiFi7
> requires it, et

Yes, (all new to me but) it seems Linux has been doing this
successfully for a while with all manner of APs, and the
Rogers/Comcast XB7 adding PMF capability is rather new, so
prima facie we can suspect the problem is with the AP here.

I will try to get the capture but it will take a while.

(I see you guys are sending to the list and cc'ing me both
(because I am not on the list and probably shouldn't be).   But since
you are on the list I took off the cc so you don't get too many copies.
Let me know iff this is not the correct thing to do).

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

[Benson Bear]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

Okay, I have little idea what I am doing, but I believe I have managed
to set one of my machines'  NIC to monitor mode (the Intel NIC) and
used it to monitor the attempt of the other machine (RT) to
connect to the AP when the machine is configured to PMF
being optional.

I have never used wireshark before but I messed around and
managed to filter out all the noise and leave only those frames
that are to or from the MAC of the NIC.   Then I took just
the initial part (including a small file transfer).   Took quite
a while to get this much figured out!

I have not tried to examine it much yet, but I imagine
any of you might be able to immediately figure something
out..

One thing I do notice, is that there are only two EAPOL
frames, the ones from the AP.   I assume that this could
be a problem with the monitor capture and not something
else because it seems the frames must be there.   I
imagine this can be inferred from the frame contents but
I havent looked into that yet.   Have to look up in
more detail the meaning of the fields.

Another thing I noticed.   I tried configuring the STA to
require PMF, and guess what?   It does not connect
AT ALL.   Another clue.

Again, I will try to look into this myself, but I pass this
on now in case any of you can produce with great ease
an analysis or need to request different data.

I will get frame captures for the PMF disabled mode,
and the PMF required mode, and I will try again to
get one with all the EAPOL frames in there.  I believe
I saw some before I did the capture to the .pcap
file.

[-- Attachment #2: optional-pmf-filtered.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 15769 bytes --]

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

[Benson Bear]

Kept working at it but where I am stuck now is that without M2
in the handshake, wireshark cannot decode the M3 to see if
the IGTK is in there.    But before I try to somehow
force M2 into the capture, I wonder if it is
better to first look at wpa_supplicant somehow to see if
it noticed anything funny about the IGTK.   As Pablo said,
M4 itself is not going to be recording any complaints but perhaps
I can find that wpa_supplicant can at least speak up locally
about it.

On the other hand, as Johannes noted, even if the PMF
was set up okay, it could be any number of things
subsequently that mess it up.

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]

On 18/04/2026 14:04, Benson Bear wrote:
> Okay, I have little idea what I am doing, but I believe I have managed
> to set one of my machines'  NIC to monitor mode (the Intel NIC) and
> used it to monitor the attempt of the other machine (RT) to
> connect to the AP when the machine is configured to PMF
> being optional.
> 
> I have never used wireshark before but I messed around and
> managed to filter out all the noise and leave only those frames
> that are to or from the MAC of the NIC.   Then I took just
> the initial part (including a small file transfer).   Took quite
> a while to get this much figured out!
The pcap is missing a lot of important frames [a probe request or a
beacon from the AP would be nice], probably a combination of bad monitor
and over filtering, but we can figure some stuff out.
> 
> I have not tried to examine it much yet, but I imagine
> any of you might be able to immediately figure something
> out..
Surprisingly, the STAs are not doing what I though there would be
doing... None of them are encrypting the action frames. Your non-AP STA
sends ADDBA requests to the AP, does not receive any ADDBA response and
eventually (~2sec) sends a DELBA with reason 0x25. The AP sends an ADDBA
request to the STA, it receives a successful ADDBA response (and ACK it)
but somehow does not process it because resends one for the same TID. So
effectively, you don't have a BA session so you have pre-11n performance
(plus both STA "spam" the channel with useless action frames).
> 
> One thing I do notice, is that there are only two EAPOL
> frames, the ones from the AP.   I assume that this could
> be a problem with the monitor capture and not something
> else because it seems the frames must be there.   I
> imagine this can be inferred from the frame contents but
> I havent looked into that yet.   Have to look up in
> more detail the meaning of the fields.
> 
> Another thing I noticed.   I tried configuring the STA to
> require PMF, and guess what?   It does not connect
> AT ALL.   Another clue.
The AP might in fact not advertised MFPC but a part of its stack might
still process the MFPC setting of the STA and end up on the state you see.
> 
> Again, I will try to look into this myself, but I pass this
> on now in case any of you can produce with great ease
> an analysis or need to request different data.
> 
> I will get frame captures for the PMF disabled mode,
> and the PMF required mode, and I will try again to
> get one with all the EAPOL frames in there.  I believe
> I saw some before I did the capture to the .pcap
> file.