mt7925e corrupts data over WiFi

Aperta
  • Qualcosa non va?
#1,127 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
c, linux
Ambito
networking, operating-systems

Direzione di ricerca

Inizia riproducendo il fallimento persistente dell’upload TLS con il driver mt7925e, confrontando al contempo i risultati su WiFi e tramite connessione cablata. Esamina il comportamento di mt76/mt792x e usa i contatori debugfs menzionati, l’output di iw station dump e i log esistenti del kernel o di NetworkManager per analizzare i percorsi AES-CCMP, di aggregazione e DMA. Il lavoro è completato quando la fonte della corruzione TX è stata isolata oppure è stato documentato un difetto concreto del driver o del firmware.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 ?

Lingua principale
C
Stelle
895
Fork
461
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openwrt/mt76

Tutte le issue di openwrt/mt76

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.