High TX retries + rate oscillation on MediaTek Filogic (mt76) – possible AMPDU / rate control issue

DienoX · May 13, 2026, 11:51pm

Hello,

I’m seeing a persistent Wi-Fi performance issue on a MediaTek Filogic (mt798x) based OpenWrt AP using the mt76 driver. The behavior strongly suggests a TX retry storm combined with rate adaptation oscillation.

Setup

Device: MediaTek Filogic (mt798x / Wi-Fi 6) Cudy WR3000P
OpenWrt: recent stable (kernel 6.x, mt76)
Mode: AP (802.11ax / HE)
Channel: 5 GHz (tested 160 MHz and 80 MHz)
TX power: 19–23 dBm
Clients: multiple devices tested (same behavior)

root@OpenWrt ~# ubus call system board                                                  {                                                                                               "kernel": "6.12.85",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "Cudy WR3000P v1",
        "board_name": "cudy,wr3000p-v1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.3",
                "firmware_url": "https://downloads.openwrt.org/",
                "revision": "r32912-6639b15f62",
                "target": "mediatek/filogic",
                "description": "OpenWrt 25.12.3 r32912-6639b15f62",
                "builddate": "1777933845"
        }
}
root@OpenWrt ~#

Symptoms

1. Extremely high TX retries


tx retries: ~1,800,000+
tx failed:  ~matches retries (almost 1:1 ratio)

2. Rate control instability (HE / AX)

From iw dev station dump:

TX bitrate oscillates heavily:
- ~1921 Mbps (HE MCS 9)
- drops to:
  - 1297 Mbps
  - 816 Mbps
  - 6.0 Mbps (legacy fallback)

3. ACK signal instability


last ack signal: -45 dBm → -82 dBm (rapid swings)
signal avg: stable (~ -65 dBm)

4. AMPDU / MAC behavior

continuous retransmissions increase
RX side remains stable
no visible beacon loss
issue mostly affects TX direction

5. Airtime behavior


airtime weight: 256 (stable)
but throughput collapses during retry bursts

Key observation

This does not look like RF coverage issue:

RSSI stable (~ -50 to -70 dBm)
no beacon loss
RX throughput stable
only TX path degrades

Reproduction pattern

Normal operation at high MCS (HE MCS 6–9)
Sudden TX degradation event
Rate drops to 6 Mbps
TX retries spike heavily
Recovery back to high MCS
Loop repeats continuously

Things already tested

160 MHz → 80 MHz (no improvement)
TX power reduction (23 → 19 dBm) (no improvement)
multiple client devices (same behavior)
stable RF conditions (no obvious interference changes)

Questions

Is this a known issue in mt76 rate control (minstrel_ht / HE adaptation)?
Could this be related to:
- AMPDU aggregation / reordering issues?
- HE MCS fallback instability?
- mac80211 rate control oscillation under load?
Are there recommended debug options for:
- rate control tracing
- AMPDU retransmission analysis
- mt76/mac80211 debug logging?

Logs available

I can provide:

iw station dump time series (1s interval)
softirq / NET_RX correlation logs
full OpenWrt debug logs if needed

Thanks in advance — this looks like a MAC/driver-level instability rather than RF issue, but I would appreciate confirmation from mt76 / mac80211 maintainers.

castiel652 · May 14, 2026, 2:04am

Starting with HE rate control is done in firmware.

What type of client are you using to test?

reinerotto · May 14, 2026, 6:11am

Having a very similar device (Cudy TR3000 v1), I can not confirm your observations.

First of all, your statement Extremely high TX retries

needs further evaluation. How many packets transmitted ? I have about 3% retries,

tx packets: 86124
tx retries: 3060

using very "conservative" config.

   tx bitrate:     54.0 MBit/s
    tx duration:    24766969 us
    rx bitrate:     54.0 MBit/s
    rx duration:    3280922 us
    last ack signal:-43 dBm
    avg ack signal: -43 dBm

    option channel '36'
    option htmode 'HE80'

Thus, as you are using the radios very high end, pushing it to the very limit, I am even expecting driver issues. And trying to avoid.

DienoX · May 14, 2026, 10:51am

Hi,

I tested two scenarios:

Cudy WR3000P as an AP, with a Samsung Galaxy S25 as the client
Cudy WR3000P operating as a STA connected to an Orange Funbox 6

I have also already purchased a Cudy WR3000H, since it is a very similar design to the WR3000P. I plan to compare Wi-Fi performance between the OEM firmware and the latest stable OpenWrt release.

The tests are performed using iperf3 with the following commands:

iperf3 -c 192.168.72.1
iperf3 -c 192.168.72.1 -R
iperf3 -c 192.168.72.1 -P 2
iperf3 -c 192.168.72.1 -P 2 -R
iperf3 -c 192.168.72.1 -P 4
iperf3 -c 192.168.72.1 -P 4 -R

The results are very consistent. When the Cudy WR3000P mainly transmits frames (for example iperf3 -c 192.168.72.1 -R), throughput is around 480 Mbps. However, when it mainly receives data (for example iperf3 -c 192.168.72.1), throughput reaches around 1100–1200 Mbps.

Could you also perform similar iperf3 tests on your devices and check whether you observe a similar Wi-Fi throughput asymmetry depending on the traffic direction (TX vs RX)?

castiel652 · May 15, 2026, 1:09am

Try not to run iperf server/client on the AP.

Do this instead:

Client <--> AP <--> Client

DienoX · May 15, 2026, 11:59am

I don't think that's the cause, because this device is capable of over 4 Gbps when connecting to 127.0.0.1. The device running the official OpenWrt firmware has packet and Wi-Fi acceleration enabled. Based on my own experience, I also don't see this issue on the official GL.iNet Beryl AX firmware where iperf3 would be too demanding for Filogic.

However, just to be sure and to rule out all possible causes, I will also run additional tests using external devices connected over 2.5 Gbps Ethernet so we can be 100% certain where the problem actually lies.

geminis3 · June 12, 2026, 12:32pm

I’m seeing the same issue with my Galaxy S25 FE connected to my Flint 2 running OpenWrt, the AP to client TX rate drops heavily, and sometimes the client becomes almost unusable until I disconnect and reconnect it. Other devices in my household work fine.

PS: I suspect this may be a MediaTek firmware issue rather than an mt76 specific bug, because the stock GL.iNet firmware shows the same behavior even though it uses the proprietary MediaTek driver instead of mt76.