6 GHz downlink stuck at MCS 2-5 while 5 GHz reaches MCS 11 at same width and signal — not EHT, MLO, width or firmware (TBE550E + Archer BE800)

[tybautf]

Client: TP-Link Archer TBE550E PCIe (BE9300) — MT7927, WiFi PCI 14c3:7927, BT USB 0489:e116
AP: TP-Link Archer BE800 (BE19000), tri-band, ~2 m line of sight, MLO disabled
OS: CachyOS, kernel 7.2.0-1-cachyos
Package: mediatek-mt7927-dkms 2.14 (pkgrel 6)
Firmware: WM Firmware Build Time: 20260414134255 (linux-firmware blob), not the build the package shipped before v2.14-6. The shadowing issue is fixed as of 2.14-6 (#104) — verified here: only the BT .bin remains, WiFi blobs come from linux-firmware. All measurements in this report are on 20260414134255; per #102 newer firmware isn't universally better, so worth stating explicitly.

Summary

Downlink rate control is badly degraded on 6 GHz: RX MCS is pinned at 2 with EHT and only reaches 5 without it, at -50 dBm with NSS 2. The same client on 5 GHz at the same width reaches MCS 11. Uplink is unaffected (MCS 8-11 throughout). Disabling EHT helps on both bands but does not fix 6 GHz. Both client and AP are TP-Link, so this is not a cross-vendor interop issue.

Full matrix

All measurements on the same firmware, MLO disabled on the AP, ~2 m from the AP, NSS 2 throughout.

Band	EHT	Width	RX MCS	RX rate	Download	Upload
6 GHz	yes	320 MHz	2	864.6 Mbit/s	617 Mbps	2363 Mbps
6 GHz	no (disable_eht=1)	160 MHz	5	1152.8 Mbit/s	836 Mbps	1431 Mbps
5 GHz	yes	160 MHz	7	1441.3 Mbit/s	871 Mbps	1713 Mbps
5 GHz	no (disable_eht=1)	160 MHz	11	2401.9 Mbit/s	1646 Mbps	2028 Mbps

The decisive comparison is rows 2 and 4: same 160 MHz width, same HE path, comparable signal — MCS 5 on 6 GHz vs MCS 11 on 5 GHz.

On the MCS/PHY figures: iw reads msta->deflink.wcid.rate, which is only written when a firmware TX status report matches a still-pending skb, and status is requested at most once per 250 ms per station. These readings were taken at idle immediately after each test and should be treated as indicative, not authoritative — RX was observed at 1729.6 Mbit/s during a transfer where the post-test idle reading showed 1441.3. The throughput columns are the reliable part of this table.

Already ruled out

• MLO — disabled on the AP (BE800, MLO network toggle off). No change: RX MCS 2 on 6 GHz either way. Given MLO (Multi-Link Operation) support #25 and the MLO hypothesis on 5 GHz client mode: TX rate control permanently stuck at 6 Mbit/s legacy (RX unaffected, EHT/HE, related to #26/#36?) #92, this seemed worth testing first.
• Channel width — 6 GHz pinned low at both 320 MHz and 160 MHz.
• Signal — -47 to -52 dBm throughout.
• BSSID / SSID — identical on all 6 GHz BSSIDs tested.
• Retries — 1.7% on 6 GHz, no error storm; this is not an RF or retry problem.

Additional observations

Rate control drift on 6 GHz. Downlink alternates between equivalent-but-poor combinations — MCS 3/NSS 2 and MCS 5/NSS 1 both landing at 576.4 Mbit/s — suggesting the AP is acting on unreliable feedback rather than hitting a hard capability limit.

Asymmetric channel width on 6 GHz. Repeatedly observed TX negotiated at 40 MHz while RX was at 160 MHz, under sustained traffic (2M+ packets), on both EHT and HE paths:

rx bitrate: 1152.8 MBit/s 160MHz HE-MCS 5 HE-NSS 2
tx bitrate:  573.5 MBit/s  40MHz HE-MCS 11 HE-NSS 2

Never observed on 5 GHz, where both directions consistently negotiate 160 MHz.

disable_eht=1 under NetworkManager. NM runs its own supplicant over D-Bus and never reads /etc/wpa_supplicant/*.conf (same wall hit in #92). Unmanaging the interface and running wpa_supplicant standalone does work — that is how the disable_eht rows above were produced. Note modprobe mt7925e disable_eht=1 silently fails with unknown parameter 'disable_eht' ignored.

Reproduction

1. Associate to a 6 GHz BSS (WPA3-Personal, ch 53 PSC, 802.11ax/be mixed, width auto up to 320 MHz), MLO disabled on the AP.
2. Run a sustained download.
3. iw dev wlan0 link shows RX pinned at EHT-MCS 2 / 864.6 Mbit/s at -50 dBm while TX negotiates MCS 8-9.
4. Repeat on 5 GHz: RX reaches MCS 7 (EHT) or 11 (disable_eht=1) at comparable signal.

Diagnostic commands used throughout:

iw dev wlan0 link
iw dev wlan0 station dump | grep -E "tx retries|tx packets|bitrate"
sudo dmesg | grep "WM Firmware" | tail -1

Pending

LAN-side iperf3 (to remove the WAN from the picture) and in-flight station dump during transfer rather than at idle — will follow up. Happy to test 6 GHz forced to ax instead of ax/be mixed, or with the 5 GHz radio disabled, if that would help narrow it down.

[tybautf]

Updated the report: the firmware-shadowing observation is now fixed in 2.14-6, confirmed on my setup. The 6 GHz RX issue is unchanged and remains the subject of this report.

[jetm]

Careful report, and the caveat you put on the MCS figures is the right one. Since you already know wcid.rate is only refreshed when a TX status matches a pending skb, I will treat the throughput columns as the measurement and the MCS columns as corroboration, which is what you asked for.

Confirming the checkable parts first. There is no disable_eht module parameter, so the message you saw is correct rather than a bug: mt7925e exposes only disable_aspm and mt7925_common only disable_clc. disable_eht is a wpa_supplicant network-block option, which is also why it does nothing under NetworkManager, exactly as in #92. Thanks also for stating your firmware build explicitly. 20260414134255 from linux-firmware is what a correctly-installed 2.14-6 should now load, and yours is the first outside confirmation that the shadowing fix in #104 does what it claims, so that is useful to me beyond this issue.

On the substance. Downlink MCS is chosen by the AP, not by this driver, so a client-side bug can only reach it through the feedback the client provides: the link-adaptation and beamforming reports the AP uses to pick a rate. That narrows where to look and it also means the interesting number in your table is not the MCS, it is that 6 GHz download sits at 617 Mbps while upload on the same link reaches 2363 Mbps. A client that could not receive well would not transmit that cleanly.

The observation I keep coming back to is the width asymmetry:

rx bitrate: 1152.8 MBit/s 160MHz HE-MCS 5 HE-NSS 2
tx bitrate:  573.5 MBit/s  40MHz HE-MCS 11 HE-NSS 2

40 MHz in one direction and 160 MHz in the other, sustained, on 6 GHz only and never on 5 GHz. Two directions of the same link should not disagree about width for long. That smells more like the driver reporting or negotiating 6 GHz channel state inconsistently than like rate control being confused on its own, and it would be consistent with the AP adapting to something it is being told rather than to what the air actually looks like. I would not call that a diagnosis yet, but it is where I would spend the next hour.

Worth knowing this driver has form on 6 GHz specifically. #75 is a 6 GHz association failure tied to band index handling, and internally mt7927_band_idx() returns the same value for 5 and 6 GHz, so the two bands are not as separable in this code as the hardware makes them. I am not claiming that is your bug; I am saying 6 GHz-only behaviour here is not surprising.

Three things would move this, in order of value.

The one I want most is the cleanest bisect available to you and it costs nothing. You are on kernel 7.2, where Sean Wang's MT7927 series is in mainline, so the in-tree mt7925e supports your card without this package at all. Uninstall it, reboot, and re-run the 6 GHz download test on the stock driver. If the ceiling is still there, this is an upstream mt76 issue and belongs on linux-wireless where the people who wrote the rate-control path will see it. If it lifts, the problem is in the four AP-mode patches this package still carries and it is mine. Either answer is worth more than any amount of further measurement here, because right now we cannot tell which codebase we are debugging.

Second, the LAN-side iperf3 you already have planned, plus station dump taken during the transfer rather than after it. The in-flight numbers are the ones that reflect what rate control actually settled on.

Third, the forced-ax test you offered. If 6 GHz at plain HE with no be in the mix behaves, that isolates this to the EHT path on 6 GHz, which is a much smaller place to look than "6 GHz".

If you would rather not uninstall the package, tell me and I will send you the same test with the AP patches reverted instead, but the stock-driver route is faster and gives a cleaner answer.

[tybautf]

Stock driver test done — the ceiling is still there.

Package uninstalled, rebooted, confirmed running the in-tree driver from kernel 7.2.0-1-cachyos:

$ modinfo mt7925e | grep filename
filename: /lib/modules/7.2.0-1-cachyos/kernel/drivers/net/wireless/mediatek/mt76/mt7925/mt7925e.ko.zst

$ dkms status
(empty)

$ sudo dmesg | grep -E "mt7925e|WM Firmware" | tail -5
mt7925e 0000:24:00.0: MT7927 raw CHIPID=0x0000, forcing chip=0x7927
mt7925e 0000:24:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260414133750a
mt7925e 0000:24:00.0: WM Firmware Version: ____000000, Build Time: 20260414134255

6 GHz, same AP and SSID (Kepler-16b_6G), MLO disabled, -52 dBm, firmware unchanged:

Driver	Download	Upload	RX	TX
DKMS 2.14-6	617 Mbps	2363 Mbps	EHT-MCS 2	EHT-MCS 8-9
in-tree (kernel 7.2)	628 Mbps	2348 Mbps	EHT-MCS 3	EHT-MCS 8

Within noise of each other. The download ceiling reproduces on stock mainline mt76, so it is not coming from the AP-mode patches this package still carries.

One thing I could not reproduce in this run: the sustained 40 MHz TX / 160 MHz RX width asymmetry. Both directions negotiated 320 MHz here. I will watch for it under sustained load and report if it returns, since that was the observation you wanted to dig into.

[tybautf]

LAN-side iperf3 done, with in-flight readings. Stock in-tree driver (kernel 7.2.0-1-cachyos), 6 GHz, MLO disabled, -51 dBm, firmware 20260414134255.

iperf3 -c 192.168.1.55 -R -t 300 against a wired LAN host:

[  5]   0.00-1.00   sec  71.0 MBytes   595 Mbits/sec
[  5]  10.00-11.00  sec  73.4 MBytes   615 Mbits/sec
[  5]  20.00-21.00  sec  71.8 MBytes   602 Mbits/sec
[  5]  30.00-31.00  sec  74.6 MBytes   626 Mbits/sec

Steady 581-632 Mbits/sec throughout, no collapse-and-recover pattern.

iw dev wlan0 link sampled during the transfer, not after:

signal: -51 dBm
rx bitrate:  864.6 MBit/s 320MHz EHT-MCS 2 EHT-NSS 2 EHT-GI 0
tx bitrate: 3843.1 MBit/s 320MHz EHT-MCS 9 EHT-NSS 2 EHT-GI 0

RX sat at MCS 2 (864.6) most of the time, stepping up to MCS 3 (1152.9) occasionally before dropping back. So rate control does attempt to climb and does not hold — consistent with the MCS 3/NSS 2 ↔ MCS 5/NSS 1 drift I reported earlier, and with the AP reacting to inconsistent feedback rather than hitting a hard capability ceiling. Throughput stayed flat regardless of which one it was on.

The WAN is not involved. ~615 Mbps on a purely local transfer matches the ~628 Mbps speedtest figure from the stock-driver run.

The 40 MHz TX / 160 MHz RX width asymmetry did not reproduce during this run — both directions held 320 MHz for the full 300 s. I will keep watching for it and report if it returns.

Forced-ax test next.

[tybautf]

Forced-ax test done — this rules EHT out. The problem is the band.

AP 6 GHz radio set to 802.11ax only (the BE800 drops max width to 160 MHz automatically, since 320 MHz is EHT-only). Stock in-tree driver, MLO disabled, firmware 20260414134255.

iperf3 -c 192.168.1.55 -R -t 60, steady 843-892 Mbits/sec throughout:

[  5]   0.00-1.00   sec   103 MBytes   864 Mbits/sec
[  5]  10.00-11.00  sec   104 MBytes   871 Mbits/sec
[  5]  20.00-21.00  sec   102 MBytes   860 Mbits/sec
[  5]  30.00-31.00  sec   104 MBytes   871 Mbits/sec

In-flight iw dev wlan0 link:

rx bitrate: 1152.8 MBit/s 160MHz HE-MCS 5  HE-NSS 2 HE-GI 0 HE-DCM 0
tx bitrate: 2401.9 MBit/s 160MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0

Side by side with the 5 GHz HE run — same width, same HE path, comparable signal:

Band	Path	Width	RX MCS	RX rate	TX MCS	Download
6 GHz	HE (ax only)	160 MHz	5	1152.8 Mbit/s	11	870 Mbps
5 GHz	HE (disable_eht=1)	160 MHz	11	2401.9 Mbit/s	11	1646 Mbps

TX reaches MCS 11 on both bands. RX reaches MCS 11 on 5 GHz and stalls at 5 on 6 GHz. With EHT out of the picture entirely and width held equal, the only remaining variable is the band itself.

Given what you said about mt7927_band_idx() returning the same value for 5 and 6 GHz, and #75 being a 6 GHz band-index issue, that seems like the place to look. Happy to test a patch or a debug build.

Summary of the three tests you asked for:

1. Stock in-tree driver — ceiling reproduces (628 Mbps vs 617 on DKMS), so it is upstream, not the AP-mode patches.
2. LAN iperf3 + in-flight dump — WAN not involved; RX genuinely at MCS 2 under load, not a stale wcid.rate.
3. Forced ax — not EHT; RX still crippled on 6 GHz at MCS 5 while 5 GHz reaches 11.

[jetm]

That is a clean bisect, and it settles the ownership question. 628 against 617 Mbps on the stock in-tree driver is within noise of the DKMS build, so the four AP-mode patches this package carries are not involved. Combined with the forced-ax run, EHT is out and width is held equal, which leaves the band as the only variable. That is three hypotheses eliminated with measurements rather than argument, and it is more than most reports ever get to.

I went looking for the obvious client-side cause and it is not there, so let me save you the trouble of chasing it. The HE MCS map this driver advertises is built from the antenna mask alone:

	int i, nss = hweight8(phy->mt76->antenna_mask);
	u16 mcs_map = 0;
	...
		mcs_map |= (IEEE80211_HE_MCS_SUPPORT_0_11 << (i * 2));
	...
	he_mcs->rx_mcs_80  = cpu_to_le16(mcs_map);
	he_mcs->tx_mcs_80  = cpu_to_le16(mcs_map);
	he_mcs->rx_mcs_160 = cpu_to_le16(mcs_map);
	he_mcs->tx_mcs_160 = cpu_to_le16(mcs_map);

There is no band term anywhere in it. The client tells the AP it can receive MCS 0-11 with NSS 2 on 6 GHz in exactly the same words it uses on 5 GHz, and the RX and TX maps are identical. So this is not the client understating what it can receive, which was the first thing I expected to find and would have been the easy answer.

That matters for where this goes next. The AP is being told MCS 0-11 and is choosing 5 anyway, on a -50 dBm link with 1.7% retries. Downlink rate selection lives in the AP, driven by what it observes and what the client feeds back, so with the advertised capability ruled out the remaining candidates are the feedback path or the chip's actual 6 GHz receive behaviour. Neither is reachable from a packaging repository, and both are firmware-adjacent.

On the mt7927_band_idx() lead, I want to be straight rather than encouraging: I raised it as a reason 6 GHz-only behaviour would not surprise me, not as a diagnosis. It returns the same index for 5 and 6 GHz, which is real, but I have not traced it to anything in the receive rate path and I would be guessing if I told you it was the cause. #75 is a genuine 6 GHz band-index bug, but it is an association failure, which is a different mechanism from a rate ceiling on an association that works.

So the honest position is that this belongs upstream on linux-wireless, where the people who wrote the rate-control path and can see the firmware side will read it. You already have everything such a report needs, which is unusual: it reproduces on stock mainline, it survives EHT removal, width is controlled, signal and retries are documented, and both directions of the same link disagree in a way that is specific to one band. Send it to linux-wireless and copy Sean Wang, who wrote the MT7927 series that landed in 7.2. Mention the in-tree reproduction in the first paragraph, because that is what stops it being triaged as a downstream packaging problem.

If you would rather I wrote it up and sent it with you credited for the measurements, say so and I will. I am glad to carry it either way, and I will keep this issue open as the pointer so anyone hitting the same ceiling finds your data rather than filing it again here.

One last thing worth recording since you have the rig set up: the width asymmetry you saw earlier, 40 MHz in one direction and 160 MHz in the other on 6 GHz, did not reappear in this run, where both directions are at 160 MHz. If you can tell whether that was tied to the EHT path specifically, it is worth a line in the upstream report, because two directions disagreeing about width is a more concrete thing for a maintainer to chase than a rate ceiling on its own.

[tybautf]

Happy for you to write it up — you know the linux-wireless conventions and Sean Wang will read it differently coming from you than from a stranger. Credit for the measurements is fine and accurate.

Thanks for the differents explanations.

On the width asymmetry, the honest answer is that I can't yet tie it to EHT with confidence. What I have:

• Observed on 6 GHz on both paths earlier in this issue — I logged it once with EHT-MCS and once with HE-MCS 5 / 160MHz RX vs 40MHz TX.
• Did not reproduce in either controlled run since: 60 s EHT at 320 MHz held 320/320 throughout, and 60 s forced-ax at 160 MHz held 160/160 throughout.
• Never seen on 5 GHz in any run.

So it is intermittent and 6 GHz-specific, but my earlier sightings were opportunistic iw reads rather than sustained monitoring, and I can't rule out that they were transient states caught at the wrong moment. I'd rather say.

I still have the rig set up. If it's worth a line in the upstream report I can run a longer watch specifically for it — sampling iw dev wlan0 link once a second through an hour transfer on 6 GHz, EHT enabled, and logging only the samples where the two directions disagree on width. That would give a reproduction rate rather than anecdotes. Say the word and I'll do it on both path (ax/be and only ax)