I don’t know off hand. But a guess is that the userspace stack is missing 6Ghz support.
Can you try a live key with Ubuntu 24.04 daily or Fedora rawhide daily and see if it’s the same situation?
1 Like
That could just be a GUI issue. Do you see the mac for the 6GHz band on your router in the output of nmcli dev wifi list?
1 Like
No, I only see the MAC for the 2.4GHz and 5GHz bands in the list.
What do you see in the output of sudo iw list for those bands - this is the output of mine on an 11th gen machine in which I replaced the AX210 with a RZ616:
...
Frequencies:
* 5955.0 MHz [1] (12.0 dBm) (no IR)
* 5975.0 MHz [5] (12.0 dBm) (no IR)
* 5995.0 MHz [9] (12.0 dBm) (no IR)
* 6015.0 MHz [13] (12.0 dBm) (no IR)
* 6035.0 MHz [17] (12.0 dBm) (no IR)
* 6055.0 MHz [21] (12.0 dBm) (no IR)
* 6075.0 MHz [25] (12.0 dBm) (no IR)
* 6095.0 MHz [29] (12.0 dBm) (no IR)
* 6115.0 MHz [33] (12.0 dBm) (no IR)
* 6135.0 MHz [37] (12.0 dBm) (no IR)
* 6155.0 MHz [41] (12.0 dBm) (no IR)
* 6175.0 MHz [45] (12.0 dBm) (no IR)
* 6195.0 MHz [49] (12.0 dBm) (no IR)
* 6215.0 MHz [53] (12.0 dBm) (no IR)
* 6235.0 MHz [57] (12.0 dBm) (no IR)
* 6255.0 MHz [61] (12.0 dBm) (no IR)
* 6275.0 MHz [65] (12.0 dBm) (no IR)
* 6295.0 MHz [69] (12.0 dBm) (no IR)
* 6315.0 MHz [73] (12.0 dBm) (no IR)
* 6335.0 MHz [77] (12.0 dBm) (no IR)
* 6355.0 MHz [81] (12.0 dBm) (no IR)
* 6375.0 MHz [85] (12.0 dBm) (no IR)
* 6395.0 MHz [89] (12.0 dBm) (no IR)
* 6415.0 MHz [93] (12.0 dBm) (no IR)
* 6435.0 MHz [97] (12.0 dBm) (no IR)
* 6455.0 MHz [101] (12.0 dBm) (no IR)
* 6475.0 MHz [105] (12.0 dBm) (no IR)
* 6495.0 MHz [109] (12.0 dBm) (no IR)
* 6515.0 MHz [113] (12.0 dBm) (no IR)
* 6535.0 MHz [117] (12.0 dBm) (no IR)
* 6555.0 MHz [121] (12.0 dBm) (no IR)
* 6575.0 MHz [125] (12.0 dBm) (no IR)
* 6595.0 MHz [129] (12.0 dBm) (no IR)
* 6615.0 MHz [133] (12.0 dBm) (no IR)
* 6635.0 MHz [137] (12.0 dBm) (no IR)
* 6655.0 MHz [141] (12.0 dBm) (no IR)
* 6675.0 MHz [145] (12.0 dBm) (no IR)
* 6695.0 MHz [149] (12.0 dBm) (no IR)
* 6715.0 MHz [153] (12.0 dBm) (no IR)
* 6735.0 MHz [157] (12.0 dBm) (no IR)
* 6755.0 MHz [161] (12.0 dBm) (no IR)
* 6775.0 MHz [165] (12.0 dBm) (no IR)
* 6795.0 MHz [169] (12.0 dBm) (no IR)
* 6815.0 MHz [173] (12.0 dBm) (no IR)
* 6835.0 MHz [177] (12.0 dBm) (no IR)
* 6855.0 MHz [181] (12.0 dBm) (no IR)
* 6875.0 MHz [185] (12.0 dBm) (no IR)
* 6895.0 MHz [189] (12.0 dBm) (no IR)
* 6915.0 MHz [193] (12.0 dBm) (no IR)
* 6935.0 MHz [197] (12.0 dBm) (no IR)
* 6955.0 MHz [201] (12.0 dBm) (no IR)
* 6975.0 MHz [205] (12.0 dBm) (no IR)
* 6995.0 MHz [209] (12.0 dBm) (no IR)
* 7015.0 MHz [213] (12.0 dBm) (no IR)
* 7035.0 MHz [217] (12.0 dBm) (no IR)
* 7055.0 MHz [221] (12.0 dBm) (no IR)
* 7075.0 MHz [225] (12.0 dBm) (no IR)
* 7095.0 MHz [229] (12.0 dBm) (no IR)
* 7115.0 MHz [233] (12.0 dBm) (no IR)
...
I see the same list of channels but without the (no IR) string:
Frequencies:
* 5955 MHz [1] (12.0 dBm)
* 5975 MHz [5] (12.0 dBm)
* 5995 MHz [9] (12.0 dBm)
* 6015 MHz [13] (12.0 dBm)
* 6035 MHz [17] (12.0 dBm)
* 6055 MHz [21] (12.0 dBm)
* 6075 MHz [25] (12.0 dBm)
* 6095 MHz [29] (12.0 dBm)
* 6115 MHz [33] (12.0 dBm)
* 6135 MHz [37] (12.0 dBm)
* 6155 MHz [41] (12.0 dBm)
* 6175 MHz [45] (12.0 dBm)
* 6195 MHz [49] (12.0 dBm)
* 6215 MHz [53] (12.0 dBm)
* 6235 MHz [57] (12.0 dBm)
* 6255 MHz [61] (12.0 dBm)
* 6275 MHz [65] (12.0 dBm)
* 6295 MHz [69] (12.0 dBm)
* 6315 MHz [73] (12.0 dBm)
* 6335 MHz [77] (12.0 dBm)
* 6355 MHz [81] (12.0 dBm)
* 6375 MHz [85] (12.0 dBm)
* 6395 MHz [89] (12.0 dBm)
* 6415 MHz [93] (12.0 dBm)
* 6435 MHz [97] (12.0 dBm)
* 6455 MHz [101] (12.0 dBm)
* 6475 MHz [105] (12.0 dBm)
* 6495 MHz [109] (12.0 dBm)
* 6515 MHz [113] (12.0 dBm)
* 6535 MHz [117] (12.0 dBm)
* 6555 MHz [121] (12.0 dBm)
* 6575 MHz [125] (12.0 dBm)
* 6595 MHz [129] (12.0 dBm)
* 6615 MHz [133] (12.0 dBm)
* 6635 MHz [137] (12.0 dBm)
* 6655 MHz [141] (12.0 dBm)
* 6675 MHz [145] (12.0 dBm)
* 6695 MHz [149] (12.0 dBm)
* 6715 MHz [153] (12.0 dBm)
* 6735 MHz [157] (12.0 dBm)
* 6755 MHz [161] (12.0 dBm)
* 6775 MHz [165] (12.0 dBm)
* 6795 MHz [169] (12.0 dBm)
* 6815 MHz [173] (12.0 dBm)
* 6835 MHz [177] (12.0 dBm)
* 6855 MHz [181] (12.0 dBm)
* 6875 MHz [185] (12.0 dBm)
* 6895 MHz [189] (12.0 dBm)
* 6915 MHz [193] (12.0 dBm)
* 6935 MHz [197] (12.0 dBm)
* 6955 MHz [201] (12.0 dBm)
* 6975 MHz [205] (12.0 dBm)
* 6995 MHz [209] (12.0 dBm)
* 7015 MHz [213] (12.0 dBm)
* 7035 MHz [217] (12.0 dBm)
* 7055 MHz [221] (12.0 dBm)
* 7075 MHz [225] (12.0 dBm)
* 7095 MHz [229] (12.0 dBm)
* 7115 MHz [233] (12.0 dBm)
I am no expert, but I believe that that indicates that the 6GHz bands are working on your laptop. You can test it by temporarily creating a 6GHz only network on your router and trying to connect to it. Best of luck.
After looking into this further, I’m left with more questions than answers. The 6GHz networks appear and disappear randomly in the list of networks (nmcli dev wifi list) and are displayed with the incorrect channel number (always 0) and bandwidth. Here’s what I see when it does find the 6GHz network:
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
XX:XX:XX:XX:XX:07 <NAME> Infra 44 540 Mbit/s 100 ▂▄▆█ WPA2 WPA3
* XX:XX:XX:XX:XX:05 <NAME> Infra 1 540 Mbit/s 99 ▂▄▆█ WPA2 WPA3
XX:XX:XX:XX:XX:02 <NAME> Infra 0 0 Mbit/s 82 ▂▄▆█ WPA3
The network with the BSSID ending in :02 is the 6GHz band, and I know it’s not dropping out because my desktop - which incidentally also uses an AMD RZ616 - remains connected. The actual broadcast channel is 165 (not 0), and the bandwidth is wrong as well (it sometimes shows 0 Mbit/s). If I try connecting to the 6GHz network using nmcli d wifi connect, I get the following error after around 10-15 seconds:
Error: Connection activation failed: The Wi-Fi network could not be found.
The connection also times out when I try connecting via the GNOME GUI. The results are consistent regardless of whether I have band steering enabled or disabled on the AP.
I’m inclined to think there’s something going on in the Linux driver for the RZ616, given that the same chipset works brilliantly on my desktop running Windows 11.
Running Gentoo and using iwd directly to manage my wireless connection.
Had bad wifi speeds, on average 10x lower than what I was able to get on my Macbook or iPhone.
Turning the card’s power save mode to off didn’t seem to change anything.
The problem was about my regulatory domain not being set correctly. For some reason it defaults to “world” at boot which is basically the most generic value, and therefore the less permissive.
With the value set to “world” iwd never considered connecting to the 6GHz access point my router exposes, as opposed to my other two devices that do. Hence the tremendous difference in speeds.
Changing it to my country’s value or any other value really fixed it and allowed iwd to connect to the 6GHz AP.
I’m still unable to make this setting persist across reboots though, if anyone has a clue about that.
To get your regulatory domain config:
iw reg get
To set it (root access needed):
sudo iw reg set US # or your country's code
4 Likes
I think if you install the wireless-regdb, you should be able to uncomment your country code in /etc/conf.d/wireless-regdom (location maybe different in Gentoo?) and it should persist on reboot.
I’ve this package installed already but no such configuration file available.
I ran a few find commands on the system but no luck, I really can’t find anything like it.
From what I’ve been reading it seems that the cfg80211 kernel module can be passed the regulatory domain as an option so I might as well try this.
Assuming OP is in the US, testing against iw reg set US is one thing to try.
Another is to disable power save, see if there is any change.
And likely the best long term item to test:
This is good to know. In my case the regulatory domain is already correctly set to Canada (I pasted the terminal output in my initial post), so this doesn’t appear to be the source of my issue. The 6GHz bands show up in the list.
I was actually able to connect manually to the 6GHz network last night using nmcli with speeds >1Gb/s in both directions. This worked until my laptop went to sleep, and now the 6GHz bands don’t show up in nmcli dev wifi list again.
@Matt_Hartley Disabling power save did improve the Wi-Fi link speed significantly, but it didn’t affect the weird behaviour I’m setting with disappearing 6GHz bands.
2 Likes
I seem to recall this being addressed in some upcoming kernels, but at this time I lack an environment with 6GHz network atm.
Are all issues with this MediaTek card be resolved now?
I have the FW16 but it comes with the same card, and I’m having performance issues as well as it seems to take out my 5GHz AP radio. Heavy traffic will knock out the 5GHz radio it’s connected to. The router (configured as an AP) has (Asus RT-AC3200) has 1x 2.4 GHz, and 2x 5 GHz radios. If I am connected to either of the 5 GHz and do a speed test (sometimes just one will do, and sometimes it takes several tests) or any other heavy traffic like Windows Update, a large Fedora update (like when going from 39 to 40), and ISO downloads, the WIFI would get knocked out and all of my devices connected to that same radio would disconnect. None of them will be able to reconnect until I toggle the radio on and off, or reboot the Asus AP.
No other devices seem to be able to do that. This is the only MediaTek WIFI card I have so not even sure if it’s defective.
I wish Framework didn’t use this card and instead went with the AX210. It’s just going to go to the landfill since I don’t see myself repurposing the MediaTek card.
Oddly, I have found numerous posts on this issue, but none of the fixes seemed to work. I was just playing with some things and succesfully connected to my 6GHz network. I already had power save disabled. So, I enabled it the disabled it again. Disconnected from my 5GHz network and attempted to connect to my 6GHz network and voila!
freq: 6135.0
signal: -48 dBm
rx bitrate: 1921.5 MBit/s 160MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
tx bitrate: 1729.6 MBit/s 160MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
wlp13s0 IEEE 802.11 ESSID:"PuppyMonkeyBaby6"
Mode:Managed Frequency:6.135 GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate=1.7296 Gb/s Tx-Power=3 dBm
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
XX:XX:XX:XX:XX:XX PuppyMonkeyBaby24 Infra 4 130 Mbit/s 100 **** WPA2 WPA3
XX:XX:XX:XX:XX:XX PuppyMonkeyBaby5 Infra 157 270 Mbit/s 87 **** WPA2 WPA3
* XX:XX:XX:XX:XX:XX PuppyMonkeyBaby6 Infra 0 61 Mbit/s 72 *** WPA3
Unfortunately, it didn’t survive a reboot and now I cannot connect to my 6GHz network even after recreating what I did…
I figured it out.
Even though you can set your region with
sudo iw reg set US
and it appears to be set when I checked. I found that in
/sys/module/cfg80211/parameters/ieee80211_regdom
it was set to world (00)
Disabling power save didn’t seem to do anything to help
Using
echo "options cfg80211 ieee80211_regdom=US" | sudo tee /etc/modprobe.d/mt7921-kernel67-fix.conf
and then reboot
Did the trick
Not sure why the region isn’t getting set correctly, but this has survived several reboots.
Hope this helps someone else.
Does anyone know what/how to get ieee80211_regdom to configure properly? I haven’t had any success searching the internet for a good answer.
5 Likes
Nice find!
For an adapter in managed (aka client) mode though, I would have expected passive scanning to be enabled for the 6GHz band by default, and so the AP to be discoverable. Isn’t the general approach that it’s up to the AP to “dictate” the regulatory domain?
That’s is my thoughts exactly. I’m really puzzled as to what really went wrong. I will say my linux install has been the same since about 2014. Just updated many times, even after a new pc build. maybe I should do a fresh install with limited restore (my files only) and see if that makes a difference.
For what it’s worth I reproduced this (regdom 00 by default, now set to US by modprobe). But in my use case it’s kind of moot as I don’t have a 6GHz AP around.
As to the cause, I dunno, leaving the regdom as “I dunno” makes sense for a mobile client device which can travel to different reg domains. So IMO it’s the adapter firmware’s (or the kernel driver’s?) decision/“fault” for not scanning at 6GHz in that scenario.
Being that there doesn’t seem to be actual firmware for the mt7921e, and it appears to “piggyback” off another driver’s firmware could be the issue in itself. I did read somewhere along this journey this “issue” has occurred with intel cards as well, although I cannot find the actual article I was reading atm. One would think, when the ip address, dhcp, etc is pulled from the carrier, the region could automatically be identified, or even when installing the wireless-regdm package, some sort of “config” process should run to identify the region at that time.