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

Alexandre Hallaine <[email protected]>
Newsgroups org.kernel.vger.linux-wireless
Message-ID <[email protected]>
Adding another data point to this thread. I'm on Videotron Helix
(Quebec, Canada) — same Technicolor CGM4331COM Rev 2.0 as the
Rogers XB7. This confirms the issue crosses ISPs using the same
Comcast xFi platform.

My client is an Intel AX210 (not yet tested in this thread),
iwlwifi driver, NixOS 26.05, kernel 6.18.44, NetworkManager +
wpa_supplicant. I also reproduced with multiple other WiFi cards,
not just Intel.

Gateway firmware: CGM4331COM_8.3p15s1_PROD_sey (newer than
BensonBear's 8.3p12s1 — bug persists).

Precise A/B measurements (same 5 GHz network, same BSSID, same
PHY — only variable is PMF):

   PMF negotiated (NM default):
     Download: 47-57 Mbps
     Latency under load: 300-1400 ms
     TX retry rate: ~35%
     PHY rate: 1200 MBit/s (HE-MCS 11, NSS 2, 80 MHz)

   PMF disabled (pmf=1):
     Download: 651 Mbps
     Latency under load: 55 ms
     TX retries: 0%
     PHY rate: identical

   iwd (no PMF by default):
     Download: 514 Mbps
     Latency: 34 ms
     TX retries: ~3.7%
     PHY rate: identical

   Minimal wpa_supplicant (no NetworkManager, bgscan=none):
     Download: 470 Mbps
     TX retries: 0%
     PHY rate: identical

Two findings I haven't seen mentioned yet:

1) I ran `iw event -t` during a download with PMF enabled.
    TX retries spiked to 15,000+ in 10 minutes, but iw event
    showed ZERO events — no scanning, no roaming, no channel
    switches, no disconnects. This rules out off-channel behavior
    as the cause. The retries are purely MAC-layer with no
    control-plane disruption.

2) Minimal wpa_supplicant without NetworkManager gets 470 Mbps
    with 0% retries. This proves wpa_supplicant itself is not the
    problem — NetworkManager's default PMF negotiation triggers
    the bug.

Regarding the kernel mechanism: Linux net/mac80211/agg-tx.c has
an explicit guard:

   "MFP STA not authorized - deny BA session request"

If PMF negotiation puts the station in an incorrect authorization
state (the mismatch Pablo described), mac80211 denies Block ACK
session establishment. Without BA sessions, A-MPDU aggregation
cannot operate. Without aggregation, each frame pays full overhead
(preamble + contention + SIFS/DIFS + individual ACK), which
mathematically produces ~24-48 Mbps at 1200 Mbps PHY rate —
matching the observed numbers exactly.

This aligns with Pablo's capture analysis: the STAs send ADDBA
requests that get no response, then DELBA with reason 0x25 —
no BA session is established, so performance is pre-11n.

For the AP side: the public RDK-B OneWifi repository has
documented PMF configuration defects:

   PR #1295 (July 2026): "WPA2personal should have mfp as optional"
   — fixes incorrect MFP configuration for WPA2-Personal

   PR #1340 (August 2026): fixes security-mode translation errors
   affecting WPA3, transition mode, and PMF handling

These confirm RDK-B has had real PMF configuration bugs. The
firmware on my gateway (8.3p15s1) may not include these fixes.

What did NOT fix it (with PMF enabled):
   - iw dev set power_save off
   - iwlwifi uapsd_disable=1 + iwlmvm power_scheme=1
   - BSSID lock
   - Disabling P2P
   - Forcing 5 GHz band

Only disabling PMF fixed it.

Workaround:
   nmcli connection modify "SSID" 802-11-wireless-security.pmf 1

I have full iw station dump output, NetworkManager logs, and
wpa_supplicant logs available. I can also run packet captures
of the AddBA/Block ACK exchange if it would help confirm whether
the AP or the client is dropping the action frames.

--
Alexandre Hallaine
NixOS 26.05, Intel AX210, kernel 6.18.44
Videotron Helix CGM4331COM Rev 2.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.