The MT7922 6GHz Debacle: Why Linux Users Can't Use WiFi 6E (And How I Fixed It)

I recently upgraded to a UniFi Dream Router 7. It has a 6GHz radio. My AceMagic W1 mini PC (AMD Ryzen 7 8745HS) has a MediaTek MT7922, a WiFi 6E chip. Both sides support 6GHz. You'd think connecting them would be straightforward.

It was not.

The Setup

My main SSID (let's call it "HomeNet") broadcasts on 2.4, 5, and 6GHz. I was connected to 5GHz. Always 5GHz. The 6GHz band was right there, beacon and all, but my machine refused to use it.

I checked the obvious things. The MT7922 hardware supports Band 4 (6GHz). The driver (mt7921e) loads fine. A passive scan picked up neighbor APs on 6GHz, so the radio works. My router was broadcasting. Everything looked correct.

First Theory: Authentication

WiFi 6E mandates WPA3-SAE on 6GHz. My main SSID uses mixed WPA2/WPA3 authentication. I figured maybe that was the problem: the router won't bring up 6GHz on a mixed-auth SSID.

So I created a new SSID that only broadcasts on 5GHz and 6GHz with WPA3-only authentication. Connected to it. Checked the frequency.

5GHz. Still 5GHz.

The SSID had "6G" in the name. The irony wasn't lost on me.

The Real Problem

Running iw phy phy0 info told the whole story. Every single 6GHz channel was flagged (no IR):

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

no IR means "no initiate radiation." The adapter can passively listen on these channels but cannot transmit first. It can hear the 6GHz beacons from my router, but it isn't allowed to respond.

This comes from the Linux wireless regulatory database (wireless-regdb). The US entry for 6GHz reads:

(5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR

That NO-IR flag is what kills 6GHz for every device that relies on the kernel's regulatory database.

The Intel Exception

Here's where it gets interesting. Intel's AX210 and AX211 cards can connect to 6GHz on Linux without touching the regulatory database.

Why? Because Intel cards use a self-managed regulatory domain, a mechanism called Location Aware Regulatory (LAR). Their firmware contains its own regulatory table and determines the country by listening to nearby AP beacons. The kernel's wireless-regdb and its NO-IR flag simply don't apply to them. The frequencies are, as Intel puts it in their FCC documentation, "set in factory in NVM, unreachable by user."

It's not perfect. If the firmware can't determine the country from surrounding beacons, 6GHz stays disabled. Users report LAR can be flaky: it sometimes picks the wrong country or fails to detect one at all. But when it works, Intel cards connect to 6GHz without any modification.

MediaTek and Qualcomm cards don't have this luxury. The MT7922, its WiFi 7 successor the MT7925, and Qualcomm's WCN7850 (ath12k) all rely on the kernel regulatory database. They're subject to whatever wireless-regdb says. And wireless-regdb says no.

The Upstream Stonewall

Someone submitted a patch to remove NO-IR from the US 6GHz entry back in February 2025. The rationale was sound: FCC rules allow client devices to transmit on 6GHz indoors, and the NO-IR restriction is overly conservative.

The patch was reviewed. The maintainer asked for a revision to keep the power limit at 12 dBm while removing NO-IR. And then... nothing. The revised patch never landed. Over a year later, the flag is still there.

For context, I checked every country entry in the regulatory database. Out of all the nations on earth with 6GHz rules, exactly two have the NO-IR flag: the United States and Honduras. Every other country, from Australia to the UK to Japan to Brazil, allows active client transmission on 6GHz just fine. So if you're a Linux user in the US, take comfort in knowing that you share your regulatory restrictions with exactly one other country.

Meanwhile, Intel cards have been connecting to 6GHz this entire time with their own regulatory implementation baked into firmware.

I can't say for certain this gives Intel an unfair advantage. But the outcome is clear: if you're a Linux user shopping for a WiFi 6E or WiFi 7 card today, Intel is the only vendor whose 6GHz works out of the box. MediaTek, Qualcomm: they're all blocked by the same two characters in a text file. Make of that what you will.

The Fix

Out of despair, I cloned the wireless-regdb source, opened db.txt, and changed one line:

- (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
+ (5925 - 7125 @ 320), (12), NO-OUTDOOR

Built it:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git
cd wireless-regdb
# edit db.txt: remove NO-IR from the US 6GHz line
python3 db2fw.py regulatory.db db.txt
sudo cp /usr/lib/firmware/regulatory.db /usr/lib/firmware/regulatory.db.bak
sudo cp regulatory.db /usr/lib/firmware/regulatory.db
sudo modprobe -r mt7921e && sudo modprobe mt7921e

Connected to WiFi. Checked the frequency.

channel 37 (6135 MHz), width: 160 MHz, center1: 6185 MHz

6GHz. 160 MHz channel width. Just like that.

An iperf3 test confirmed over 1 Gbps throughput. The connection was stable. Everything just worked, because two characters were removed from a text file.

Making It Survive Updates

The wireless-regdb package will overwrite your custom regulatory.db on the next update. On Arch, a pacman hook takes care of it:

# /etc/pacman.d/hooks/wireless-regdb-custom.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = wireless-regdb

[Action]
Description = Rebuilding custom regulatory.db (NO-IR removed for US 6GHz)...
When = PostTransaction
Exec = /bin/sh -c 'python3 /usr/local/share/wireless-regdb/db2fw.py /usr/lib/firmware/regulatory.db /usr/local/share/wireless-regdb/db.txt'

Store your modified db.txt and the db2fw.py script somewhere persistent (I used /usr/local/share/wireless-regdb/), and the hook rebuilds the binary automatically after every package update.

The State of 6GHz on Linux

It's 2026. WiFi 6E has been out for years. WiFi 7 routers are shipping. Both standards rely on the 6GHz band for their fastest speeds and widest channels. And on Linux, if you don't have an Intel card, the 6GHz band is blocked by a two-character flag in a regulatory text file. It doesn't matter if your card is WiFi 6E or WiFi 7. If it uses the kernel's regulatory database, 6GHz is off limits.

The fix is a one-line change to a text file that has been sitting in a mailing list for over a year. Every major distribution ships with this restriction. Every non-Intel WiFi 6E and WiFi 7 card is affected.

If you have an MT7922, or any non-Intel WiFi 6E adapter, and you want 6GHz on Linux, the steps above will get you there. You shouldn't have to do this. But until that patch lands upstream, you do.

Disclaimer

This was done strictly for research and validation purposes. After confirming that the MT7922 is fully capable of 6GHz operation on Linux, and that the only barrier is a regulatory database flag, I reverted to the original regulatory.db. Modifying the wireless regulatory database may violate FCC regulations in your jurisdiction. If you reproduce these steps, I encourage you to do so only to validate your own 6GHz-capable equipment, and to restore the original database afterward.