I know I’m late to the convo, but I’ve also been dealing with this issue for months.
A temporary patch is available, but an official kernel patch is in the works. In a nutshell comcast routers ,possibly even back to the XB6, are broadcasting the router’s abilities as requirements. Likely a copy/paste error or misconfig. There is a patch available on github from WoodyWoodster which you might want to look into.
You’ll likely need to run this command to disable pmf if you get any slowdowns or spikes on ping:
nmcli connection modify "YOUR_WIFI_NAME" wifi-sec.pmf 1
nmcli connection up "YOUR_WIFI_NAME"
I’ll include the info I have from my own repo for a patched Bazzite build:
I’ll do my best to explain this from the information I’ve gathered, but I’m not a specialist in this field. Just a guy trying to get his wifi working.
Certain routers, namely the XB7 or later routers (XB6 may also be affected) from Comcast (Technicolor and Sercomm models confirmed to be affected), have a software bug that likely resulted from a copy/paste of the router capabilities into the basic MCS requirements for the older 802.11n (HT) and 802.11ac (VHT) standards. 802.11ac and ax are not affected, 802.11be is not yet confirmed as it was disabled on my router, but there shouldn’t be an issue. The Mac80211 kernel module by default adheres strictly to the ieee 802.11 standards and disables the HT capabilities when it sees these incorrect Basic MCS Set from the router. While thise likely differs from behavior in Windows and MacOS, it is technically the correct way to handle the situation. Some users may wish, however, to have the option to bypass this to make their wifi usable until a fix is integrated into the kernel.
This patch modifies the source file mlme.c in mac80211 to align HT mcs checks with how VHT mcs checks are performed by only verifying mcs in strict mode. This line is what already exists in the kernel where mac80211 checks the VHT MCS set agains what the router is requiring:
/*
* Many APs are incorrectly advertising an all-zero value here,
* which really means MCS 0-7 are required for 1-8 streams, but
* they don't really mean it that way.
* Some other APs are incorrectly advertising 3 spatial streams
* with MCS 0-7 are required, but don't really mean it that way
* and we'll connect only with HT, rather than even HE.
* As a result, unfortunately the VHT basic MCS/NSS set cannot
* be used at all, so check it only in strict mode.
*/
if (!ieee80211_hw_check(&sdata->local->hw, STRICT))
return true;
Authored by @benzea and committed by @jmberg-intel The initial commit can be found here: (link redacted)
My patch simply inserts the same line into the similar HT function just above it.
+ * Similar to the issue below with VHT, some APs, mainly Comcast XB7+,
+ * are advertizing an all-F value, meaning the AP is requiring MCS
+ * 0-76 in order to connect with HT. Connection to the affected 2.4
+ * and 5ghz bands will fall back to legacy 802.11a/g,even if the
+ * hardware and regulations support VHT or HE (and presumably EHT)
+ * HT Basic MCS set cannot be used, so check only in strict mode
+ * as is done in the VHT section.
+ */
+ if (!ieee80211_hw_check(&sdata->local->hw, STRICT))
+ return true;
This instructs mac80211 to ignore the MCS verification and enable HT anyway until Comcast fixes their firmware or the kernel devs implement a bypass. I can confirm that VHT is indeed being falsely advertised as well, but VHT is already patched in the kernel while HT is not. This is the text from the commit:
wifi: mac80211: add HT and VHT basic set verification So far we did not verify the HT and VHT basic MCS set. However, in P802.11REVme/D7.0 (6.5.4.2.4) says that the MLME-JOIN.request shall return an error if the VHT and HT basic set requirements are not met.
Given broken APs, apply VHT basic MCS/NSS set checks only in strict mode.
While the VHT issue had to do with all-zero entries into the Basic MCS Set for VHT, the issue with HT is actually the opposite with all f’s, but the result is functionally the same. HT:
9d 05 17 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
The first few pairs are simply things like the channel, offset/width, and protection bits. The series of f’s, however, is why things fail. Those are the bits that dictate the requirements that any client needs to meet in order to associate at high speed. To do this would require four spatial streams, while most wireless cards support only 2. When mac80211 receives this information from the wireless driver, it disables HT when it sees that the hardware can’t meet those requirements.
For reference here is what this looks like in VHT:
01 2a 00 00 00
In this case though, the 0 represents that the client must support MCS 0-7 in the 4 TX and 4 RX streams. This issue had been fixed in early 2025 however. I can only assume that this issue is only now appearing for HT because companies have shifted their focus towards newer standards. It is likely that the router’s supported MCS were simply copied and pasted into the Basic MCS Set at some point during development.