mt7996 (W1700K, 6 GHz HE160): Apple HE clients' uplink falls to legacy 54 Mbps without A-MPDU until reassociation; multiple clients flip at the same moment

Open
  • Is something wrong?
#1,179 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
24/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
networking

Research direction

Start by reading the mt7996 driver and firmware handling for HE uplink rates, aggregation, and station state; the report does not name a source file or test. Reproduce the rate drop and capture AP and client state at the flip, using the supplied logs and station samples as starting points. Done means identifying the AP-side trigger and documenting or fixing the cause; the issue asks which state to capture and does not yet isolate the cause.

Written by the indexing model from the issue text.

Description

Summary

On 6 GHz (ch 85, 160 MHz), Apple macOS clients (HE, BCM4388) sometimes switch their uplink to legacy OFDM 54 Mbps and stop sending A-MPDUs. They stay that way for hours until the client reassociates. Downlink stays at HE-MCS 7–9 the whole time. Signal does not change and no frames fail. Twice, two different Macs flipped in the same minute, which points to a trigger on the AP side or in the air rather than inside one client. A Wi-Fi 7 (EHT) client on the same BSS was not affected.

Hardware / software

  • Device: Gemtek W1700K (Airoha AN7581 + MT7996, Wi-Fi NPU offload active, mt7996e.wed_enable=N)
  • OpenWrt SNAPSHOT r37939-a516fe3151, kernel 6.18.55
  • mt76 0936617d (2026-10-28, master tip at time of writing)
  • MT7996 WM/WA/DSP firmware build 20260721; NPU fw 0.1111 (20261019)
  • AP: 6 GHz, channel 85, EHT160 (he_oper_centr_freq_seg0_idx=79), country US, txpower 23 dBm, single BSS, SAE
  • hostapd: he_bss_color=128, he_twt_responder=1, he_spr_sr_control=3, he_6ghz_reg_pwr_type=0, default MU-EDCA parameters
  • Clients:
    • Mac mini (Mac16,10), macOS 26.7.1 (25G241), Broadcom BCM4388, fw 23.50.20.2.41.51.209 — 2x2 HE160
    • MacBook Air (Apple silicon, macOS 26.x) — HE
  • Unaffected: an EHT (Wi-Fi 7) client on the same BSS

Symptom (from both sides)

AP (iw dev phy0.2-ap0 station get) for the stuck station:

tx bitrate: 1729.6 MBit/s 160MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
rx bitrate: 54.0 MBit/s                       <- stays like this while traffic is flowing (inactive time < 1 s)

Client (macOS airportd LQM, sampled every 5 s), healthy, then the flip:

23:29:19 LQM txRate=1633.3Mbps txFail=0 txRetrans=2 txFallbackRate=816.7Mbps rxRate=1441.2Mbps
         LQM-WiFi txAMPDU=44 rxBACK=39 txUcast=68 rxACKUcast=24
23:29:24 LQM txRate=54.0Mbps   txFail=0 txRetrans=0 txFallbackRate=18.0Mbps  rxRate=1441.2Mbps   <- rate drops first
         LQM-WiFi txAMPDU=24 rxBACK=22
23:29:29 LQM txRate=54.0Mbps   txFail=0 txRetrans=0
         LQM-WiFi txAMPDU=0 rxBACK=0 txUcast=42 rxACKUcast=42                                    <- then A-MPDU stops, every frame single-ACKed
  • Client RSSI stays the same (−43 dBm), and txFail/txRetrans stay at 0 after the flip.
  • Client order of events: the uplink rate drops first, and A-MPDU stops 5–10 s later. So losing aggregation looks like a result of the legacy rate, not the cause.
  • At the flip the AP hears the client 7–12 dB weaker (e.g. −62 → −74 dBm). This fits the client sending in a different PHY format, not a real path-loss change.
  • Block-ack state on the AP does not change: RX BA sessions for the station stay active with the same dialog tokens from before the flip (debugfs agg_status). The client logs no ADDBA/DELBA (rxdelba=0).
  • Station debugfs flags look the same as on a healthy client.
  • Only reassociation recovers it (toggling Wi-Fi on the client, or a deauth from the AP). Right after rejoining, the client runs HE-MCS 6–9 at the same signal level.

Episodes (UTC)

# Flip Clients Connected before flip Stuck for
1 2026-11-06 05:43 Mac mini – ~9 min (ended by radio restart)
2 2026-11-06 07:26:30 Mac mini ~1 h 20 min ~10 h (until rejoin)
3 2026-11-07 01:41:37 Mac mini and MacBook Air (Air within ~1 min; it was idle) ~8 h / ~6 h until rejoin
4 2026-11-07 07:29:19 Mac mini and MacBook Air (same 60 s AP sample) ~3 h (since AP reboot) ~10 h 15 min (until rejoin)

No fixed timer: time connected before the flip ranged from 1 h 20 min to about 8 h.

What the AP logged around the flips

Nothing that lines up with the flips:

  • no kernel warnings, no mt76 messages
  • no hostapd events for the affected stations, no radio reload, no channel or txpower change
  • normal load; 6 GHz channel busy about 3 %
  • the only hostapd lines nearby are routine (usteer BTM to an unrelated 2.4/5 GHz station, and a steady "Unexpected Link measurement report, token 1", 6 every 30 s, which also appears during healthy periods)

Ruled out

  • U-APSD: set uapsd_advertisement_enabled=0 on the 6 GHz BSS (cf. reports of Apple stalls with U-APSD). Episode 4 happened with it off.
  • Txpower changes: a phy-wide txpower blip did not reproduce it, and in episode 2 a 2.4 GHz power change came 16 min after the flip.
  • Signal / interference: the client's RSSI did not change, and a second Mac in another room flipped at the same moment.
  • The NPU rx crash (#1169): no WARNs during episodes 2–4.

Possibly related

  • openwrt/mt76 #1169 (NPU rx ring handling, W1700K) — not in this build; no crash during these episodes.
  • GL-MT3600BE mt7996 fix for WCID per band, described as "station gives up on aggregation until a new session starts" — similar symptom. (TODO: add link)

Questions

  1. Is there a known AP-side event on mt7996 (BSS color collision/change, MU-EDCA or spatial-reuse parameter update, TWT, beacon IE change, or a firmware rate-table/WTBL reset) that could make HE clients fall back to legacy uplink at the same moment?
  2. Which debugfs/firmware state would be most useful to capture at the moment of the flip? We can snapshot automatically within a few seconds of detection.

Logs (AP syslog plus 60 s station samples, and client LQM logs) are available for all episodes.

Dominant language
C
Stars
895
Forks
461
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/mt76

All issues in openwrt/mt76

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.