I’ll post here if I get it to work. Currently all 6Ghz range channels show as disabled. Country code is set to US. I recall this working a while back on an earlier kernel, but I haven’t been able to dig back up the thread where that was discussed, either here or elsewhere.
Any pointers or wisecracks appreciated.
Have a good day.
Found the original thread here: Kernel 5.16 6Ghz Disabled AX210 - #8 by D.H. Thanks again to @ryanpetris and @D.H. @DHowett, would there be any way to set that value with the ectool?
Rebooted to kernel 5.15.94 and the 6GHz channels are available, reconfirming the information in the linked thread. @Matt_Hartley, it sounds like this may be something that may need to be fixed in firmware if the maintainers of iwlwifi don’t see fit to change it.
I’m happy to test things out if it would be any help.
Thanks all, and have a good evening.
So just wanted to make sure I know some additional details:
Which distro and release are you using?
What router and mode are you using?
Hi @Matt_Hartley, thanks for the reply.
I’m running Manjaro GNOME, kernel 6.1.12-1-MANJARO. I booted it back to kernel 5.15.94-1 to confirm that wifi 6e was working.
The router is an ASUS GT-AXE11000 running merlin firmware 388.1. It’s in router mode with three non-wifi 6e mesh nodes connected to it via wired ethernet. The router’s in tri-band mode. If needed I can flip the 6e out to it’s own SSID since currently only my phone is capable of connecting in the 6GHz bands, unless I roll back the laptops to an older kernel.
I also have a family machine, which I believe is still on Pop!_OS 22.04. I can fire that up if there’s any useful information to be gleaned from it.
This would be awesome if this is on a similar wifi chipset. If not, it would be worth us checking your logs.
journalctl | grep iwlwifi
To see if anything interesting is showing there. If nothing pops up, we can open a ticket to take a closer look.
To clarify, my primary machine is a batch 1 framework 11th gen i7. The family machine is a later batch 11th gen i5, after the switch of the audio chip iirc. Both have the ax210.
Both machines work fine, they just won’t use the 6GHz bands since kernel 5.16 as noted in the linked post from D.H above.
Here’s the output of journalctl | grep iwlwifi. I anonymized the base station mac address for posting:
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: enabling device (0000 -> 0002)
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: api flags index 2 larger than supported by driver
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.63.2.2
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: loaded firmware version 66.f1c864e0.0 ty-a0-gf-a0-66.ucode op_mode iwlmvm
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: loaded PNVM version 0x64acdc51
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: Detected RF GF, rfid=0x10d000
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0: base HW address: de:ad:be:ef:de:ad
Mar 11 22:04:10 manjaro kernel: iwlwifi 0000:aa:00.0 wlp170s0: renamed from wlan0
Mar 11 22:04:14 manjaro NetworkManager[919]: <info> [1678590254.6831] rfkill0: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:1d.0/0000:aa:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
Mar 11 22:04:18 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:06:33 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:12:46 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:13:41 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:14:34 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:15:35 manjaro kernel: iwlwifi 0000:aa:00.0: Not associated and the session protection is over already...
Mar 11 22:15:37 manjaro kernel: iwlwifi 0000:aa:00.0: Not associated and the session protection is over already...
Mar 11 22:15:39 manjaro kernel: iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: enabling device (0000 -> 0002)
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: api flags index 2 larger than supported by driver
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: loaded firmware version 72.daa05125.0 ty-a0-gf-a0-72.ucode op_mode iwlmvm
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: loaded PNVM version 64acdc51
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: Detected RF GF, rfid=0x10d000
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0: base HW address: de:ad:be:ef:de:ad
Mar 11 22:30:25 manjaro kernel: iwlwifi 0000:aa:00.0 wlp170s0: renamed from wlan0
Mar 11 22:30:26 manjaro NetworkManager[749]: <info> [1678591826.1281] rfkill0: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:1d.0/0000:aa:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
You can see it load the older firmware when I’m booted to the 5.15 kernel, and the newer firmware when I booted back to 6.12.
Here is the current output of iw list, trimmed to show the 6GHz bands disabled:
Frequencies:
* 5955 MHz [1] (disabled)
* 5975 MHz [5] (disabled)
* 5995 MHz [9] (disabled)
* 6015 MHz [13] (disabled)
* 6035 MHz [17] (disabled)
* 6055 MHz [21] (disabled)
* 6075 MHz [25] (disabled)
* 6095 MHz [29] (disabled)
* 6115 MHz [33] (disabled)
* 6135 MHz [37] (disabled)
* 6155 MHz [41] (disabled)
* 6175 MHz [45] (disabled)
* 6195 MHz [49] (disabled)
* 6215 MHz [53] (disabled)
* 6235 MHz [57] (disabled)
* 6255 MHz [61] (disabled)
* 6275 MHz [65] (disabled)
* 6295 MHz [69] (disabled)
* 6315 MHz [73] (disabled)
* 6335 MHz [77] (disabled)
* 6355 MHz [81] (disabled)
* 6375 MHz [85] (disabled)
* 6395 MHz [89] (disabled)
* 6415 MHz [93] (disabled)
* 6435 MHz [97] (disabled)
* 6455 MHz [101] (disabled)
* 6475 MHz [105] (disabled)
* 6495 MHz [109] (disabled)
* 6515 MHz [113] (disabled)
* 6535 MHz [117] (disabled)
* 6555 MHz [121] (disabled)
* 6575 MHz [125] (disabled)
* 6595 MHz [129] (disabled)
* 6615 MHz [133] (disabled)
* 6635 MHz [137] (disabled)
* 6655 MHz [141] (disabled)
* 6675 MHz [145] (disabled)
* 6695 MHz [149] (disabled)
* 6715 MHz [153] (disabled)
* 6735 MHz [157] (disabled)
* 6755 MHz [161] (disabled)
* 6775 MHz [165] (disabled)
* 6795 MHz [169] (disabled)
* 6815 MHz [173] (disabled)
* 6835 MHz [177] (disabled)
* 6855 MHz [181] (disabled)
* 6875 MHz [185] (disabled)
* 6895 MHz [189] (disabled)
* 6915 MHz [193] (disabled)
* 6935 MHz [197] (disabled)
* 6955 MHz [201] (disabled)
* 6975 MHz [205] (disabled)
* 6995 MHz [209] (disabled)
* 7015 MHz [213] (disabled)
* 7035 MHz [217] (disabled)
* 7055 MHz [221] (disabled)
* 7075 MHz [225] (disabled)
* 7095 MHz [229] (disabled)
* 7115 MHz [233] (disabled)
Those are enabled when booted to the 5.15 kernel
I was about to post about having this problem as well, but I tracked it down to a different issue and decided to post in case it may help someone else. I have setup a new network with 6 GHz channels using Unifi U6 Enterprise APs and the only device (of those capable) that would not connect to a 6 GHz channel was my Framework laptop (running Pop_OS 22.04 w/ kernel 6.2.0). Android phones were using 6 GHz channels just fine. But my list of 6 GHz channels in iw list on the laptop were not listed as (disabled) and instead only (no IR) which, to my understanding, is fine and expected on the AX210. Not only that, but it was seeing my wifi networks being broadcast on 6 GHz. I decided to try and create a new network that was only broadcast on 6 GHz and… sure enough, I could connect to it. After deleting that network, I would still only connect to a wifi network broadcast on all three bands at 5 GHz. After disabling band steering on this particular wifi network within Unifi, suddenly the Framework would connect to 6 GHz channels right away. I’m not sure how that particular feature is implemented, but it clearly did not affect Android phones and only Linux devices using AX210 cards.
https://bugzilla.kernel.org/bugview/206469.html
Apparently this is an Intel issue. More discussion here.
@Michael_Frick - what country are you in? I see the 6GHz channels disabled in both Manjaro and Pop!_OS. I’m in the US. Thanks.
@lbkNhubert I’m also in the US. I may have run sudo iw dev wlp... scan beforehand to try and get it to pick up the correct locale for LAR as I’ve tried so many things the last few days. But I haven’t reboot after discovering the band steering issue yet. I’ll try that soon and report back.
I did some more testing and think I’ve found the issue (for me) - the 6 GHz is just always weaker than 5 GHz on my Framework and so it’s never chosen unless the network is only broadcast on 6 GHz. Trying a few distances from an AP, adjusting different band’s power (6 GHz on High, 5 GHz on Low), etc always resulted in the 5 GHz channel being at least a few dB better as seen by sudo iw dev wlp166s0 scan | grep ^BSS -A10 | egrep '(BSS|freq|signal|SSID)'.
So my 6 GHz is working, but it may just be that the antennas on the Framework don’t pick up 6 GHz all that well. Which is a shame because despite having a phy rate of 2,400 Mbps up/down on either channel, my real world upload is about double on 6 GHz (~800 Mbps on 6 GHz vs ~450 Mbps on 5 GHz). At least the download speed is in the low 900 Mbps range on either, so I’ll take it.
If there’s any other troubleshooting you’d like me to do that might help anything along here, I’m happy to do it, just ask!
@Michael_Frick thanks for the additional info. Is your machine 11th or 12th gen? What do you see in the output of iw reg get?
On my manjaro machine I get:
global
country US: DFS-FCC
.
.
.
phy#0 (self-managed)
country US: DFS-UNSET
but I edited th regdom.conf file to point it to US settings.
The Pop!_OS machine is on its defaults and also reports the 6GHz bands as disabled. As note earlier they do work if I boot back to a 5.15.x kernel. I’m at a loss.
Yeah, I guess it’s worth noting exactly what I have and how it’s seen. 
I have the 12th gen with the i7-1260P. Pop_OS was installed with a combination of a guide to setting it up on BTRFS with automatic snapshotting (should be irrelevant here) and the Framework guide which has a couple of hardware tweaks (mic jack, fingerprint reader, etc) but nothing directly related to wifi. On boot for kernel 6.2.0-76060200-generic:
[ 20.038612] iwlwifi 0000:a6:00.0: enabling device (0000 -> 0002)
[ 20.052818] iwlwifi 0000:a6:00.0: api flags index 2 larger than supported by driver
[ 20.052835] iwlwifi 0000:a6:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[ 20.053316] iwlwifi 0000:a6:00.0: loaded firmware version 72.daa05125.0 ty-a0-gf-a0-72.ucode op_mode iwlmvm
[ 20.230064] iwlwifi 0000:a6:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
....
[ 20.417934] iwlwifi 0000:a6:00.0: Detected RF GF, rfid=0x10d000
[ 20.513522] iwlwifi 0000:a6:00.0 wlp166s0: renamed from wlan0
And then general output from iw list:
Frequencies:
* 5955 MHz [1] (22.0 dBm) (no IR)
* 5975 MHz [5] (22.0 dBm) (no IR)
* 5995 MHz [9] (22.0 dBm) (no IR)
* 6015 MHz [13] (22.0 dBm) (no IR)
* 6035 MHz [17] (22.0 dBm) (no IR)
* 6055 MHz [21] (22.0 dBm) (no IR)
* 6075 MHz [25] (22.0 dBm) (no IR)
* 6095 MHz [29] (22.0 dBm) (no IR)
* 6115 MHz [33] (22.0 dBm) (no IR)
* 6135 MHz [37] (22.0 dBm) (no IR)
* 6155 MHz [41] (22.0 dBm) (no IR)
* 6175 MHz [45] (22.0 dBm) (no IR)
* 6195 MHz [49] (22.0 dBm) (no IR)
* 6215 MHz [53] (22.0 dBm) (no IR)
....
And from iw reg get:
global
country 00: DFS-UNSET
(755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
phy#0 (self-managed)
country US: DFS-UNSET
(2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
(2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
(2447 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
(5170 - 5190 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS
(5190 - 5210 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS
(5210 - 5230 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS
(5230 - 5250 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS
(5250 - 5270 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
.... snip ....
(5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-160MHZ
(5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-160MHZ
(5815 - 5835 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
(5945 - 5965 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(5965 - 5985 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(5985 - 6005 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6005 - 6025 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6025 - 6045 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6045 - 6065 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6065 - 6085 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6085 - 6105 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6105 - 6125 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6125 - 6145 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6145 - 6165 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6165 - 6185 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6185 - 6205 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6205 - 6225 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6225 - 6245 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
(6245 - 6265 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN
(6265 - 6285 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN
....
And if I run sudo iw reg set US then the only difference in the iw reg get output afterward is the global section that changes, but there’s no difference in terms of how anything operates from what I’ve seen.
global
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
I know that was a wall of output, but I hope that helps!
@Michael_Frick - thanks for all of the info! I won’t be able to do more digging for a few days. What I am going to try to look into is if there is some difference in the firmware between the 11th and 12th gen machines. In the thread linked in my second post in this thread, @ryanpetris notes that there is a value being passed in the bios. I will have to enable debugging for iwlwifi and see what I get. If you are willing to do so, can you see what you get on your 12th gen machine? If it is different than what I get in the 11th gen I will put in a request that Framework investigate it and plan to patch the 11th gen firmware if that is determined to be the appropriate fix.
Thanks again for your help with this. This is a great community and you’re showing why.
Have a great day.
@lbkNhubert I went ahead and tried to compile the 6.2.7 kernel with CONFIG_IWLWIFI_DEBUG=y… but failed… multiple times/different ways. 
If you can point me in the right direction to successfully building a kernel on Pop_OS with iwlwifi debugging enabled, I’m happy to take a look.
My Manjaro system is connecting to my 6Ghz network just fine after setting up the network on kernel 5.15, then switching to kernel 6.2. Screenshot shows the kernel version and the output of iw list showing the frequencies being enabled.
Thanks @Blake_Weldon - it looks like you are on a 12th gen system as well as @Michael_Frick. I’m back at my machines now and will be looking into if I can get iwlwifi in debug on the Pop!_OS machine. I can on my manjaro one, but I need to set it then unload and load the moduie to see if I can trigger the message that @ryanpetris saw in the log.
@Matt_Hartley - I presume that you have access to both 11th and 12th gen systems - are you willing to try to test this out on both? I lack a 12th gen on which to test and had not been planning to upgrade my 11th gen systems to 12th. Thanks!
Another data point:
MT7921K and MT7921AU WiFi chips and associated kernel modules have no problem attaching to 6ghz APs. Using arch kernels 5.18.x through 6.2.x on 11th Gen i5 framework .
Getting those chips to make a 6ghz AP requires regulatory domain spoofing, but they do work if you do.
100% agreed that the problem is Intel and their ridiculous Location (un)Aware Registry implementation. LAR is so borked that a single AP heard with mismatching regulatory domain locked out all DFS channels.
Mediatek may not be the performance kings at the moment, but their kernel drivers are way more respecting of open source software principles. GitHub - morrownr/USB-WiFi: USB WiFi Adapter Information for Linux has way more details than I can parrot here if you care to look into it.
I shan’t be buying any more closed blob garbage Intel wifi chips.
@D.H that link is broken, do you have another? I’m curious to read more about this.
Edit: To be clear, I’m talking about
As my understanding was that Intel had the best network adapters. I’m a WiFi 4 chip myself that doesn’t need binary blobs but I’d be interested in a newer chip that requires very little binary blobs for a substantial uplift in performance (and security which is more relevant to me anyways).
Link fixed.
