mt7925e corrupts data over WiFi

Summary

mt7925e reliably corrupts data during sustained/large TX transfers over WiFi (TLS records fail integrity check on the receiving server — net::ERR_SSL_BAD_RECORD_MAC_ALERT), while the radio/MAC layer reports a completely clean link (no deauth, no beacon loss, tx failed: 0). The same transfer succeeds immediately and reliably when routed over a wired connection (USB tethering) instead of this WiFi adapter, isolating the fault to the WiFi TX path.

Hardware

• Adapter: MediaTek MT7925 802.11be 160MHz 2x2 PCIe [Filogic 360] (Lenovo laptop, subsystem e0ff)
• Driver: mt7925e (in-tree mt76/mt792x stack)
• ASIC revision: 79250000
• Firmware: WIFI_MT7925_PATCH_MCU_1_1_hdr.bin / WIFI_RAM_CODE_MT7925_1_1.bin, HW/SW Version 0x8a108a10, build 20260605184651a / WM firmware build 20260605184805
• linux-firmware package version: 20260810
• Kernel: 7.1.8 (linuxPackages_latest on NixOS)
• Kernel cmdline includes pcie_aspm=off; module loaded with disable_aspm=1

Symptom

Large uploads (multi-MB email attachments via a web app, ~2-8MB each) fail consistently with:

Failed to load resource: net::ERR_SSL_BAD_RECORD_MAC_ALERT
[default] Failed to upload attachment (X MB, ~200-280ms) Error: Failed to load undefined

The same failure mode also manifests as repeated connection drops on a long-lived HTTPS/streaming session (an AI CLI tool making sustained API calls) on the same host/network.

What's been ruled out

• Signal strength: consistently strong throughout testing, -44 to -52 dBm.
• DFS channel instability: originally associated on channel 104 (5745MHz, DFS band); forced router to fixed channel 36 (non-DFS) — issue persisted identically.
• Power management: iw dev wlan0 set power_save off applied and verified persistent across resume/reconnect (via NetworkManager dispatcher script) — no change.
• PCIe ASPM: disabled via both pcie_aspm=off kernel param and disable_aspm=1 module option — no change.
• NIC checksum/segmentation offload: tx-checksumming and scatter-gather are already off at the netdev level (computed in software), GSO forced off as a dependency — rules out a kernel-side TSO/checksum-offload bug as the corruption source; points at the driver/firmware's own TX path (framing, aggregation, or hardware AES-CCMP encryption) instead.
• Router/AP: same corruption on two different physical BSSIDs (2.4GHz and 5GHz radios) on the same AP;
• Not a radio-layer link problem: iw station dump shows tx failed: 0, beacon loss: 0 throughout every failure — only elevated tx retries (consistently 15-25% of tx packets, even on a fresh, strong link), which never correlates with the exact timing of the corruption events in kernel/NetworkManager logs.
• Not the server or browser: identical file, identical destination, over wired USB tethering (bypassing this adapter entirely) — uploads succeed immediately, every time.

Reproduction

1. Associate to a 5GHz AP (VHT80, verified on both DFS channel 104 and non-DFS channel 36).
2. Perform a sustained TX-heavy operation over TLS — a multi-MB HTTPS upload, or a long-lived HTTPS/streaming session.
3. Observe TLS record corruption reported by the remote endpoint (bad_record_mac alert), while local radio stats show no disconnect/beacon-loss/tx-failure.
4. Repeat the identical operation over a wired connection — succeeds without issue.

Ask

Has anyone else seen TX-side data corruption (as opposed to the more commonly reported roaming/MCU-timeout/throughput issues) on mt7925e? Any pointers on how to isolate this further — debugfs counters for hardware AES-CCMP encryption errors, aggregation-related corruption, or DMA issues ?

Start by reproducing the sustained TLS upload failure with the mt7925e driver while comparing WiFi and wired results. Review mt76/mt792x behavior and use the mentioned debugfs counters, iw station dump output, and existing kernel or NetworkManager logs to investigate AES-CCMP, aggregation, and DMA paths. Done means isolating the TX corruption source or documenting a concrete driver or firmware defect.