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

I think you didn't test the right version, it should be SNAPSHOT r21968-acd8e94d20.

The auc build with the new mt76 driver just got finished early this morning Fri Feb 3 02:25:38 CET 2023. I built mine from sources yesterday.


I see. Just download the latest auc build r21968-acd8e94d20 and tested the upload again.
The upload issue in AX mode is fixed! Same spot upload jumped from 4 Mbits/sec to 487 Mbits/sec. Thanks!


Sorry for the probable stupid question...
Where can I find r21968-acd8e94d20 snapshot for download?

auc or https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=mediatek%2Fmt7622&id=linksys_e8450-ubi


I am using UBI version. If you are not, make sure you type and pick the correct name.


As OP I can report that the latest snapshot in fact did improve 802.11ax performance in this case (AX6S with a brick wall between the wifi device and the access point).

So it does prove that in fact there was an issue in the m76 drivers.

However, while 802.11ax download performance is better than 802.11ac, upload performance is still slower in 802.11ax (snapshot) when compared with 802.11.ac (22.03.3) - but at least now not as bad as it was before, to the point that 802.11ax is now usable.

I just tested with an iPhone 13P and a MacBook Air M1 at the "problematic spot". Below are the iperf3 results (more details about the test configuration in the OP):

802.11ac Mac M1: 685/626 Mbps (download/upload) - 22.03.3
802.11ax Mac M1: 806/567 Mbps (download/upload) - Snapshot r21989-5155200f97

802.11ac iPhone 13 Pro: 550/473 Mbps (download/upload) - 22.03.3
802.11ax iPhone 13 Pro: 565/442 Mbps (download/upload) - Snapshot r21989-5155200f97

I do hope 802.11ax performance with mt76 open source drives keep improving, hopefully reaching at least the same performance as 802.11ac in all situations as expected.


Well, I am surprised that nobody has pointed out the exact mt76 commit that fixed it (note: I haven't tested anything, and therefore cannot confirm the fix). Is it known?


It's one from this list: mt76: update to the latest version, import WED related mtk_eth_soc patches
They were merged into master snapshots with the same commit, so it's harder to bisect, as you will need to install older version(s) of the mt76 driver separately from OpenWRT.

Edit: anon_openwrt beat me to it xD

1 Like

Hi guys. I am running 23.03.3 official release. If I checkout that branch in git and then some how merge the new mt76 driver into it, can I build it and then scp over the mt76 driver without flashing a new image, just giving the mt76 driver/matching kernel?

I don't think so... openwrt-22.03 uses the 5.10 kernel but the following expects you to be on the 5.15 kernel for RT3200. Maybe someone else with more knowledge can comment.

1 Like

@msilletti You can always try. I regularly backport mt76 bumps to the stable release myself, but @darksky might be right that the more recent mt76 bumps rely on functionality only a newer wireless stack provides e.g. (mac80211 in master is 6.1; on 22.03 it's 5.15).

The kernel itself is of less importance, since the whole wireless subsystem has been split on purpose to allow for easier backporting. That's the whole reason 22.03 can have a 5.10 kernel e.g., but still use the newer 5.15 wireless stack.

It certainly doesn't hurt to try, you'll know soon enough if it works or not - if compilation breaks because of missing functions e.g. You can cherry-pick the mt76 bumps from master into your tree (going back all the way to the version that is now in the 22.03 tree) and give it a shot.


I used to do this (update only mt76 driver on the stable branch by editing package/kernel/mt76/Makefile and point it to the most recent version), but @darksky is correct. It stopped working when master branch was upgraded to kernel 5.15, while stable branches are on 5.10 (at least for the devices I use).

@nbd since the latest mt76 drives did improve 802.11ax of mt7915 (on mt7622 devices), please consider backporting it to the current stable branch (22.03).

That would surprise me, I think you are mistaking coincidence for causality. See my explanations above.

% git cherry-pick --strategy=recursive -X theirs acd8e94
Auto-merging package/kernel/mt76/Makefile
[openwrt-22.03 8367c66923] mt76: update PKG_SOURCE_HASH

That gave errors relating to libxml. I tried the similar bump to it but still got errors so I gave up

Your git fu is definitely superior to mine :wink:. I did the same exercise, but manually.

I'm on 22.03 with up till mt76 master commit 3968529285 cherry-picked on top. That turned out to be the most stable for my MT7915 devices.

So I filtered the master commit log until that bump:

$ git log --oneline|grep mt76:|head -14
acd8e94d20 mt76: update PKG_SOURCE_HASH
ff4c872c7c mt76: fix typo in PKG_SOURCE_DATE
521efb62eb mt76: update to the latest version, import WED related mtk_eth_soc patches
9a07895729 mt76: add stand-alone MT7622 firmware package
fc9dd3f083 mt76: add stand-alone MT7915 firmware package
3410f010a2 mt76: remove unnecessary dependency from mt7915e
274dfcb19e mt76: update to the latest version
a75a798162 mt76: update to the latest version
b1b29ba987 mt76: update to version 2022-12-01
6f729163b1 mt76: move the mt7921 firmware to its own package
9179f484bf mt76: update to the latest version
2403428c75 mt76: update to the latest version
94d0cb9d2e mt76: add firmware package for mt7916
3968529285 mt76: update to the latest version

You can skip e.g. 94d0cb9d2e (which cannot be cherry-picked cleanly but is not needed on 22.03), 6f729163b1, 3410f010a2 and the latter's two firmware package friends. But cherry-picking b1b29ba987 will break, because of the ethernet patches it introduces for 5.15. That's probably very difficult to entangle, so yes, you'll need 5.15 because of the dependency on the ethernet patches.

Sorry, I might have expressed myself not clearly enough (English is not my native language).

What I was trying to say is this:

  1. OpenWrt build gets the mt76 files directly from https://github.com/openwrt/mt76 (it is on a separate repository from main OpenWrt repository)

  2. File package/kernel/mt76/Makefile points to the exact commit in the mt76 respository to be included in the build

  3. Using branch 22.03, if I point mt76 drivers to the same one used by master (see below), 22.03 build fails due to the fact that current mt76 drivers now depends on kernel 5.15.

Anyway, this is what I used to do and it worked up to the point that snapshot changed kernel to 5.15, when the above process stopped working.

Of course you can clone mt76 repository to the same commit used by 22.03, change your OpenWrt build to point to your custom mt76 respository and cherry pick only the change you want. But this is a different route than what I was doing.

Master/Snapshot current package/kernel/mt76/Makefile


since the latest mt76 drives did improve 802.11ax on mt7622 devices

Smallest of nitpicks here... doesn't 802.11ax run off the mt7915 chip, and the mt7622 runs 802.11b/g/n?


You're absolutely right, I just updated my post above to make this clearer.

Thanks, it's been super confusing trying to understand everything as a newcomer.

The "mt76" driver package (is that what it's called overall?) has code for all sorts of chips, including the mt7622 and mt7915. Is that much correct, at least?