MT7986 (ASUS TUF-AX6000) + mt7921e client: full disconnect when active client-to-client traffic occurs on the same band, preceded by repeated SMPS mode flapping

Environment

• Router: ASUS TUF-AX6000, OpenWrt (please fill in: cat /etc/openwrt_release)
• Radio: MT7986 (phy0 = 2.4GHz, phy1 = 5GHz), driver mt798x-wmac
• Affected client: laptop with MT7922 (mt7921e driver), Debian 13, kernel 7.013 running a Docker container (media server) reachable on the LAN
• Second client: Android 14 phone Samsung A52, acting as a client of the Docker service on the laptop
• SSIDs: separate 2.4GHz (xxxx3) and 5GHz (default_radio1 'xxxx2)) interfaces, no Smart Connect/band steering combining them

Summary
The laptop (MT7922/mt7921e) and an Android phone are both associated to the same radio/band. As long as there is no active traffic between the two clients, the connection is fully stable on either band. The disconnect only occurs when the phone opens an active session against a service running in a Docker container on the laptop (a media-streaming app) — i.e. sustained client-to-client (intra-BSS) traffic on the same radio. When the two clients are on different bands, the same client-to-client session runs for hours without issue.

Observed pattern in logs
Once the client-to-client session starts, hostapd repeatedly logs SMPS mode changes for the laptop's STA within minutes, flapping between off and dynamic every 5–20 seconds:

hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 dynamic
hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 off
hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 dynamic
...
hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:88:91

No deauth reason code is logged alongside the disconnect in most cases (plain AP-STA-DISCONNECTED, no preceding IEEE 802.11: disassociated/deauthenticated due to... line).

What was tried

• Disabling disassoc_low_ack on both AP interfaces (workaround for related MT7986 issue #888): no measurable improvement in a short test window. Reverted.
• Forcing powersave off on the laptop's wifi adapter (NetworkManager wifi.powersave = 2): not conclusively tested in isolation from the band-separation workaround.
• Reliable workaround: keep the two clients on different bands. With that in place, the same client-to-client Docker session ran for 7+ hours without a single disconnect or SMPS flap.

Suspected mechanism
Sustained intra-BSS (client-to-client) traffic on the same radio appears to trigger repeated SMPS renegotiation on the mt7921e client, which shortly precedes a full disconnect. This suggests either a rate/power renegotiation loop specific to intra-BSS forwarding on MT7986, or a client-side (mt7921e) response to that traffic pattern that the AP doesn't handle gracefully.

Question / request

• Is intra-BSS traffic handling on MT7986 known to behave differently from client-to-WAN traffic (e.g. regarding SMPS/rate renegotiation)?

Logs

Pattern repeats reliably: SMPS mode flapping (off/dynamic) within seconds of each other, followed by a bare AP-STA-DISCONNECTED with no preceding deauth/disassoc reason code — i.e. the radio appears to drop the session rather than the client cleanly disconnecting.

[2026-07-17 10:20:15] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 off
[2026-07-17 10:20:32] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 dynamic
[2026-07-17 10:20:37] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 off
[2026-07-17 10:20:45] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 dynamic
[2026-07-17 10:21:36] hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:88:91
[2026-07-17 10:21:40] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: authenticated
[2026-07-17 10:21:40] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: associated (aid 3)
[2026-07-17 10:21:40] hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:88:91 auth_alg=open

Repeated in the same session, shorter interval:

[2026-07-17 10:19:32] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 dynamic
[2026-07-17 10:19:41] hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:88:91
[2026-07-17 10:19:45] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: authenticated

And again:

[2026-07-17 10:26:39] hostapd: phy1-ap0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:88:91 off
[2026-07-17 10:28:40] hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:88:91
[2026-07-17 10:28:44] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: authenticated

For comparison, a control period with the same two clients on different bands (no client-to-client Docker traffic contention): 7+ hours associated, zero SMPS flaps, zero unexpected disconnects:

[2026-07-17 10:45:42] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: authenticated
[2026-07-17 10:45:42] hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:88:91 auth_alg=open
... (no further lines for this STA until) ...
[2026-07-17 13:01:17] hostapd: phy1-ap0: STA xx:xx:xx:xx:88:91 IEEE 802.11: authenticated
(gap explained by unrelated manual switch power-cycle, not part of the reported issue)

Start by examining the mt798x-wmac and mt7921e interaction described by the hostapd SMPS and disconnect logs, comparing same-band intra-BSS traffic with the different-band control case. Done means narrowing the failure to a reproducible driver or wireless behavior and identifying the additional trace, test, or code location needed for a fix.