Bug report: mt7925e - TDLS key install fails with -ENOENT (no peer sta_info) on 5 GHz, tearing down the WiFi link

i've had some surprises today with my wifi connection. while running a service through a tailscale network, the wifi link dropped. this could probably be related to https://github.com/openwrt/mt76/issues/1094

i let claude check what's going on, the following is its bug report with trace data, i hope it helps fixing

thx for your good work

---

One-line summary

On a MediaTek MT7925 (mt7925e) adapter, when wpa_supplicant sets up a
TDLS direct link to a peer STA on the same BSS (5 GHz), installing the TDLS
peer key (TPK) fails: mac80211's ieee80211_add_key returns -ENOENT
because there is no sta_info for the TDLS peer — the driver key path is
never reached. ~60–90 s later the failed TDLS setup tears the infrastructure
link down (Reason 3 local deauth + supplicant-failed, multi-second outage) or
forces a fast band roam (Reason 6). Deterministic on 5 GHz; not attempted on
2.4 GHz.

Component

• Subsystem: wifi / mt76 / mt7925e (TDLS peer-station / key path; possible
  MLO interaction). Failure surfaces in mac80211 ieee80211_add_key.

Affected system

Item	Value
Adapter	MEDIATEK MT7925 802.11be (Filogic 360), 2x2 160 MHz, PCIe
PCI ID	14c3:7925 (subsystem AzureWave 1a3b:6001), bus c1:00.0
Driver	mt7925e
ASIC revision	79250000
Firmware	HW/SW 0x8a108a10 build 20260106153007a; WM FW build 20260106153120
linux-firmware	20260319.git217ca6e4.1ubuntu
Kernel	7.0.0-27-generic (7.0.0-27.27)
Distro	Ubuntu 26.04 LTS
wpa_supplicant	v2.11
Host	Acer laptop, AMD "Krackan" (Ryzen AI, Radeon 840M/860M)
AP	AVM FRITZ!Box, SSID gaci; 5 GHz ch40/5200 MHz (BSSID …c0:ca, VHT80 2SS) and 2.4 GHz ch6/2437 MHz (BSSID …c0:c9)
Regulatory domain	AT (DFS-ETSI)
WiFi power save	on
iw list	reports Device supports T-DLS (tdls_mgmt, tdls_oper)

What triggers it

TDLS (802.11z) lets two STAs on the same AP exchange data directly.
wpa_supplicant initiates TDLS when it sees sustained direct traffic to another
STA in the same BSS.

Here the trigger is a Tailscale (WireGuard, v1.98.4) peer-to-peer connection:
an Android phone (Tailscale node, WiFi MAC c2:b5:4e:e8:ef:79) on the same
WLAN reaches a local service on this host over Tailscale; Tailscale uses a direct
same-LAN path, the station-to-station traffic makes wpa_supplicant start TDLS to
the phone's MAC, and the failure below follows.

Tailscale is only the trigger, not the cause — any sustained direct traffic
to a same-BSS peer STA should reproduce it. Confirmed: with the peer on cellular
(off the shared WLAN) there is no direct path, no TDLS, and no problem.

Band dependence (5 GHz only)

• Associated on 5 GHz (…c0:ca, ch40, VHT80): TDLS is attempted and fails
  every time → link drop. Deterministic.
• Associated on 2.4 GHz (…c0:c9, ch6): wpa_supplicant does not even
  attempt TDLS for the same peer/workload — no TDLS: Creating peer entry, no
  key install, no drop. Verified.

Forcing the client to 2.4 GHz (nmcli connection modify <conn> 802-11-wireless.band bg) is an effective workaround. This points at the 5 GHz /
VHT / EHT-MLO configuration of the TDLS peer-station path.

Steps to reproduce

1. Associate the MT7925 host to an AP on 5 GHz (WPA2/WPA3).
2. Associate a second STA (a phone) to the same AP/BSS.
3. Generate sustained direct traffic between the two STAs (here: reach a service
   on the host from the phone over a Tailscale direct connection).
4. wpa_supplicant initiates TDLS → key install fails → link drops ~60–90 s later.

Expected vs. actual

• Expected: TDLS setup succeeds, or fails gracefully and falls back to
  AP-relayed traffic, leaving the infrastructure link up.
• Actual: the TDLS peer key install fails (-ENOENT), and ~60–90 s later the
  infrastructure link is torn down and re-associated (multi-second outage, or
  a ~1 s cross-band roam), repeated on every TDLS attempt.

Root cause (narrowed via kretprobes)

bpftrace kretprobes on the add_key call chain (kernel 7.0.0-27-generic):

[wpa_supplicant] ieee80211_add_key: NEW_KEY received          # TDLS TPK install
[ret] ieee80211_add_key (->nl80211) = -2                      # -ENOENT; nothing below ran

[wpa_supplicant] ieee80211_add_key: NEW_KEY received          # a normal (non-TDLS) key
    mt7925_mcu_add_key             = 0
    ieee80211_key_enable_hw_accel  = 0
    ieee80211_key_link             = 0
[ret] ieee80211_add_key (->nl80211) = 0                       # success, full chain

• The TDLS TPK install returns -2 (-ENOENT) from ieee80211_add_key,
  before ieee80211_key_link / ieee80211_key_enable_hw_accel / the driver
  (mt7925_mcu_add_key) are ever called.
• A normal key on the same interface goes through the full chain and the
  driver returns 0 — so mt7925e's key path itself works.

ieee80211_add_key returns -ENOENT when sta_info_get() finds no station for
the pairwise key's mac_addr. So at TPK-install time mac80211 has no sta_info
for the TDLS peer — the TDLS peer-station was never successfully added (or not
on the link mac80211 looks up). The failure is therefore in TDLS peer-station
setup, upstream of the key install — not a driver key-format rejection. It only
manifests on the 5 GHz (VHT/EHT, likely MLO) association, consistent with known
MLO/link-handling weaknesses in mt7925.

Matching user-space log (every occurrence):

wpa_supplicant: TDLS: Creating peer entry for c2:b5:4e:e8:ef:79
wpa_supplicant: TDLS: Dialog Token in TPK M1 19
wpa_supplicant: nl80211: kernel reports: key addition failed   # = ieee80211_add_key -ENOENT
wpa_supplicant: TDLS: Failed to set TPK to the driver

Two observed outcomes (~60–90 s after the failed TPK)

• Hard teardown (disruptive): deauthenticating … by local choice (Reason: 3=DEAUTH_LEAVING), locally_generated=1, NetworkManager
  supplicant-failed → multi-second outage. (e.g. TPK fail 01:01:43 → deauth
  01:03:14 → reconnect 01:03:17.)
• Fast roam (barely noticeable): Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA,
  immediate re-association to the other band (5 GHz → 2.4 GHz), ~1 s recovery.

In both cases the TDLS key-install failure is the antecedent; a failed TDLS setup
should never disturb the infrastructure link.

Likely fix directions (for maintainers)

• Ensure the TDLS peer station is registered (sta_info present on the
  correct link) before the TPK key install — the failure is -ENOENT from
  ieee80211_add_key, i.e. a missing peer sta, not a driver key rejection.
  Likely in mt7925's TDLS / MLO sta-add path. and/or
• If TDLS cannot be supported on the 5 GHz/MLO config, stop advertising TDLS so
  the supplicant never attempts it.
• Make a failed/aborted TDLS setup not tear down the infrastructure link.

Ruled out

• Not the driver key path: mt7925_mcu_add_key returns 0 for normal keys; it
  is never reached for the failing TDLS key.
• Not the AP: reproduces against an AVM FRITZ!Box; client-side TDLS sta/key.
• Not Tailscale config: tailscale serve only publishes the local port; the
  cellular and 2.4 GHz tests kept it and did not fail. Tailscale only creates the
  same-LAN direct path that triggers TDLS.
• Resolved by removing the peer from the same BSS (cellular) or by forcing the
  host onto 2.4 GHz.

Related upstream work (does NOT cover this issue)

• "wifi: mt76: mt7925/mt792x: comprehensive stability fixes" (kernels 6.17–6.19)
  — MLO roaming/ROC/deadlocks/BA; no TDLS patch.
  https://patchew.org/linux/20260105002638.668723-1-zbowling@gmail.com/ ·
  https://lkml.org/lkml/2026/1/3/61
• MT7925 known-issues tracker — MCU timeouts on MLO roaming, perf, deauth cycles;
  TDLS not mentioned. https://zbowling.github.io/mt7925/issues/known-issues/
• Ubuntu "MT7925 wifi fails to reconnect" (different symptom):
  https://bugs.launchpad.net/bugs/2111778
• Generic TDLS: Failed to set TPK to the driver on other drivers:
  https://bbs.archlinux.org/viewtopic.php?id=215799 ·
  https://github.com/morrownr/88x2bu-20210702/issues/226

Workarounds (current)

• Force 2.4 GHz (no TDLS attempted, so no drops):
  sudo nmcli connection modify gaci 802-11-wireless.band bg && sudo nmcli connection up gaci
  (revert: set the band back to empty). Trade-off: lower throughput. Confirmed.
• Keep the peer off the same WLAN (cellular) — avoids the direct path.
• Use the host on wired Ethernet — the bug is WiFi-only.
• Disabling TDLS would also work but there is no clean runtime toggle (AP-side
  prohibit, or rebuild wpa_supplicant without CONFIG_TDLS) — last resort.

Reproduce the kretprobe evidence

sudo bpftrace -e '
kprobe:ieee80211_add_key                { printf("\n[%s] ieee80211_add_key\n", comm); }
kretprobe:mt7925_mcu_add_key            { printf("    mt7925_mcu_add_key            = %d\n", retval); }
kretprobe:ieee80211_key_enable_hw_accel { printf("    ieee80211_key_enable_hw_accel = %d\n", retval); }
kretprobe:ieee80211_key_link            { printf("    ieee80211_key_link            = %d\n", retval); }
kretprobe:ieee80211_add_key             { printf("[ret] ieee80211_add_key = %d\n", retval); }'
# then, with the host on 5 GHz, drive direct traffic from a same-WLAN peer.
# The TDLS add_key shows ieee80211_add_key = -2 with no inner calls.

Start by tracing the TDLS key-install path around mac80211's ieee80211_add_key and mt7925's TDLS peer-station setup; the report shows the failure returns -ENOENT before mt7925_mcu_add_key. Reproduce on 5 GHz with a same-BSS peer using the supplied bpftrace command, then verify that TDLS setup no longer fails or disrupts the infrastructure link.