mt7921e / MT7922: connectivity failures during phone-initiated TDLS setup

[vakevk@gmail.com]

With an MT7922 (mt7921e) in station mode, an Android phone on the same
AP regularly sets up a TDLS link to the laptop when it opens a
connection to it (iperf3). This causes two failures:

1. TX from the laptop over the TDLS direct link never reaches the
    peer. This happened for 6 of 6 links. The phone tears the link
    down after 0.1-0.4 s (reason 25) or after ~10 s (reason 26).

2. In 3 of the 6 links, all unicast TX from the laptop to the AP also
    stops being delivered. This starts within 0.4 s of the link being
    enabled, persists after the TDLS teardown, and recovers on its own
    after 24-86 s. The connection to the AP is not lost and there is
    no reassociation, rekey or kernel message.

Blocking TDLS frames (ethertype 0x890d) with nft avoids both.


Environment
-----------
Device:    MT7922 [14c3:0616], subsystem Lenovo [17aa:e0c6]
Kernel:    6.18.54 (NixOS)
Firmware:  WM ____000000, build 20260724143402
            HW/SW 0x8a108a10, build 20260724143257a
Userspace: wpa_supplicant 2.12 via NetworkManager 1.56.0
AP:        AVM FRITZ!Box [model, FRITZ!OS version],
            5 GHz ch 60, 160 MHz, WPA2-PSK (CCMP), reg domain DE
Peer:      [phone model / Android version], -41 dBm at the laptop
Params:    disable_aspm=N, disable_clc=N; runtime-pm=1, deep-sleep=1


Timeline (local time; "enabled" = TDLS_OPER enable_link)
--------------------------------------------------------
enabled       teardown (reason)  TX to AP lost  MPDUs sent to AP
                                                 during the loss
12:37:23.194  12:37:33.4 (26)    86 s           ~1760
12:39:24.123  12:39:24.2 (25)    24 s           ~710
12:40:16.452  12:40:24.2 (25)    no             -
12:40:39.447  12:40:39.9 (25)    no             -
12:40:42.516  12:40:52.3 (26)    no             -
12:41:21.200  12:41:31.2 (26)    no             -
12:42:55.426  12:43:06.7 (26)    80 s           ~1590

In every link where data was flowing, mac80211 started a TX BA session
to the TDLS peer on TID 0 within 25-560 ms of enable_link (TX_START,
then TX_OPERATIONAL 2-81 ms later). The three outages began
0.1-0.4 s after enable_link.

The station already had an active TX BA session to the AP on TID 0
(agg_status, aqm flags "RUN AMPDU").


Observations during the AP outages
----------------------------------
- RX from the AP keeps working. The AP's unicast ARP requests and
   IPv6 neighbor solicitations to the laptop arrive (tcpdump on the
   STA), and the laptop transmits a reply to each. The AP keeps
   re-requesting, so the replies are never delivered.

- The AP acknowledges the laptop's frames at the MAC level:
   * Per ethtool -S, tx_ampdu_cnt is about equal to rx_ba_cnt.
   * ba_miss_count stays low.
   * Station dump for the AP shows tx failed = 0 and few retries.

- In mac80211, all queue stop/wake events (reason 7 FLUSH, 8, and 3)
   are balanced.

- No kernel log messages from mt7921e or mac80211 appear during the
   capture.

- Recovery coincides with no host-side event in the ftrace
   (mac80211 + cfg80211 events) or in the wpa_supplicant debug log.

- The MPDU counts in the table come from summing the ethtool
   tx_mpdu_success deltas over each outage window.


Observations during TDLS links
------------------------------
- The station dump shows the TDLS peer with "TDLS peer: yes". TX
   packets to it increment with 4-13 retries each and tx failed 0, but
   pings to the peer get no replies for the whole link lifetime.

- On every setup, wpa_supplicant logs "Failed to set TPK to the
   driver" (rdev_add_key returns -ENOENT before the station is
   authorized). The retry after the STA entry is complete succeeds,
   and TDLS_OPER enable_link returns 0.

- wpa_supplicant adds the peer with aid=1 ("TDLS workaround").


Reproduction
------------
1. Run iperf3 -s on the laptop.
2. Run an iperf3 client on the phone against the laptop, in either
    direction. Both directions were affected.
3. The phone initiates TDLS (discovery, then setup) within a few
    seconds. Throughput drops to 0. In about half of the attempts,
    pings from the laptop to the AP also fail.


I have a full capture and can share it on request:
- ftrace of mac80211, cfg80211 and mt76 events
- tcpdump of control traffic
- wpa_supplicant debug log
- per-second station dump, ethtool -S, aqm and debugfs snapshots

---

I debugged this for a couple of hours with an LLM which also wrote this 
report. Apologies if that is undesirable. I don't understand the details 
well enough to write it up myself.