[Solved] 802.11ax worse than 802.11ac with mt76 driver?

I don't know. For the record: For now, this is just a proposal in the mailing list. I don't know the exact procedures. It might get merged into linux-next first, before it gets merged into the linux kernel and then backported to OpenWrt with kernel 6.1 or 5.15. Usually, not everything gets backported, as it requires dedicated people with time and willingness to do this job. There are simply too many changes upstream to backport them all. Sometimes there are also compatibility issues with older kernels. Any backport can cause new bugs to pop up.

Interesting find.
Latest commit in the linux repo from three weeks ago is also from the same guy with a similar fix from the month before.

wifi: mac80211: recalc chanctx mindef before assigning
When we allocate a new channel context, or find an existing one
that is compatible, we currently assign it to a link before its
mindef is updated. This leads to strange situations, especially
in link switching where you switch to an 80 MHz link and expect
it to be active immediately, but the mindef is still configured
to 20 MHz while assigning. Also, it's strange that the chandef
passed to the assign method's argument is wider than the one in
the context.
Fix this by calculating the mindef with the new link considered
before calling the driver.
In particular, this fixes an iwlwifi problem during link switch
where the firmware would assert because the (link) station that
was added for the AP is configured to transmit at a bandwidth
that's wider than the channel context that it's configured on.


Are there any news? What's next. Does the patch help? Has anyone been able to test it yet? or is the 160Mhz support finally kicked out?

Barely any news. At least not in official repositories and forums. One user reported that in newest snapshot sometimes it works, if you just restart the device often enough. Like 1/10.

Tried with these two and no luck still slow speed compared to when VHT160 is removed. https://lore.kernel.org/linux-wireless/20230604120651.377adf3c789a.I91bf28f399e16e6ac1f83bacd1029a698b4e6685@changeid/

Haven't gotten this patch to apply and compile on the current backport but might give it another shot soon.


The AX upload performance bug for Apple AX devices is still present in 23.05.0-rc1.

Test on 23.05.0-rc1:
AX 80 MHz

34.0 Mbit/s, 80 MHz, HE-MCS 0, HE-NSS 1, HE-GI 1
680.6 Mbit/s, 80 MHz, HE-MCS 7, HE-NSS 2, HE-GI 1

iperf3 Upload: 14 Mbit/s

AC 80 MHz

390.0 Mbit/s, 80 MHz, VHT-MCS 4, VHT-NSS 2, Short GI
585.1 Mbit/s, 80 MHz, VHT-MCS 6, VHT-NSS 2, Short GI

iperf3 Upload: 289 Mbit/s

This seems to be a low level wifi OSI layer 1 bug since only the upstream connection drops to HE-MCS 0 and HE-NSS 1, while the downstream connection stays at higher connection rates.


Is this only Apple device specific? Because I tested with Chromebook (Intel AX211 WiFi) with my WAX206 on 23.05 RC1, a rough speed test gave me ~1.3Gbps throughput. Now I am trying to get an iPad mini to test with it.

Haven't done iperf because I was borrowing iPad Air 4 from someone just for a quick test.
I only used Ookla speedtest, with my WAX206 on 23.05-RC

Download: 650Mbps
Upload: 600Mbps

Luci is showing HE-NSS 2,HE-MCS10 for both TX/RX (while there is also HE-GI 1 at the end) for corresponding iPad Air 4 device.

To me it doesn't really doing bad on AX.

P.S. My WAX206 was set to 160MHz 802.11ax mode.

1 Like

This is specific to AX Apple iOS/iPadOS devices with the MT7915 device operating in AX mode, 80 MHz channel.

The upstream connection drops to HE-MCS0 (zero) NSS1 single stream during upload test.

160 MHz channels are not useful in dense city environments with a lot of other 5 GHz networks around, as you will both receive a lot of interference from other 5 GHz network and also produce interference for others. Also the more wide the channel is the more noise you will collect as a receiver.

In the EU regulatory domain there is only one 160 MHz channel available that is not shared with weather radar. 160 MHz channels could be useful for green field rural use cases here.

160 MHz channels are out of specification for MT7915, Mediatek has dropped support for these channels.


But in my case, I am also using iPad OS but there seems to be no issue, though I set my channel width to 160MHz but Apple devices can only support 80MHz so AP side will continue to use 80MHz to connect, right? I am trying to understand why I don't see the performance degrade with iPad mini 4 + WAX206 combination.

iPad Mini 4 is an AC device, not AX capable.

1 Like

The one I used to test was iPad Air 4, not iPad Mini 4, which is 802.11ax standard, and from Luci, or other routers I can see it connecting with link rate > 1000Mbps which definitely not 2x2 AC.

WAX206 seems to be using MT7975AN and not MT7915 like on eg Belkin RT3200 which is one of device that has this problem.

Also how far away from the router are you testing? The performance just a few meter away from the router is fine also on MT7915, it's when you move a little bit further away and/or have some obstacles in the way that it gets very slow.

I am looking at these 2 links:

Both are using MT7915AN + MT7975AN?? Other than the extra RTL8221B on WAX206 (which provides 2.5G WAN port), I don't really see much difference between them.

OK I was testing in the same room (it was just a quick test), since now I made a mistake and soft bricked it, I will restore it and test with a room divider or upper/lower level separation later.

1 Like

RT3200/E8450 and WAX206 both use MT7915 as 5 GHz AX controller and MT7975 RF front end

MT7975 devices: wikidevi.wi-cat.ru

1 Like

Are you in the same room? Notice that the issue I reported (I'm the OP) there is a brick wall between the access point and the device. In the same room with a line of sight between the Access Point and the device it works fine.

It does affect more Apple devices (specially upstream Wi-Fi), but non-Apple devices still suffers to a minor degree.

Yes, the same room, but now my router is soft-bricked so I need another few more days to re-flash it back to try it in different ways.

WAX206 is nmrpflash compatible, you should be able to unbrick it in this way: https://openwrt.org/docs/guide-user/installation/recovery_methods/nmrpflash

Or via TFTP: https://openwrt.org/toh/netgear/wax206#tftp_initramfs

1 Like

Oh nice, didn't know there is NMRP utility (I just found an old laptop to setup OS for TFTP), will try on that route, thanks.

An updated mt76 driver has been committed today to master branch (snapshot builds), including various changes (see commit notes below).

If I have time I will test it on the weekend to see if there is any improvement on the 802.11ax issue with the updated mt76 driver.