On MediaTek MT7925 (Connac3), QoS Data frames whose destination WCID is a TDLS direct-link peer are silently dropped after submission to firmware via the HW_80211_ENCAP TX path. The driver sees submit and complete counts match (firmware reports success on TX queue submission), but the frames never reach the PHY. iw counters show tx_packets growing, tx_failed = 0, tx_retries low; on the air, nothing. This breaks TDLS direct-link as soon as a peer auto-initiates one (Samsung phones do this aggressively when both peers share a BSS and traffic exceeds a threshold). Pattern is: 1. Any sustained direct traffic between two STAs sharing the BSS reaches the auto-TDLS threshold within ~1 s. 2. Peer initiates TDLS; mac80211 routes data frames to the TDLS-peer WCID and the AP stops forwarding peer-to-peer traffic per the 802.11z spec. 3. Direct-link frames are accepted by firmware, completed in the TX descriptor pool, but never PHY-transmitted. 4. TCP collapses; the peer eventually tears down the TDLS link with reason WLAN_REASON_TDLS_TEARDOWN_UNSPECIFIED. Cycle repeats. Effective TCP throughput drops from ~300 Mbit/s (AP route) to ~6 Mbit/s with TDLS active. Verified on mt7925e (PCIe) at 5 GHz HE NSS 2 MCS 11 80 MHz and at 2.4 GHz 802.11n HT NSS 2 MCS 15. With this patch, TDLS direct link sustains ~750 Mbit/s and ~130 Mbit/s respectively. mt76 advertises WIPHY_FLAG_SUPPORTS_TDLS via the shared mt76_register_phy_helper() but does not provide TDLS-aware firmware-facing peer setup: no CONNECTION_TDLS constant in mt76_connac_mcu.h, no STA_REC_TDLS TLV, no TDLS bit in mt76_wcid_flags, and no TDLS-specific code in mt7925_mac_write_txwi_8023(). TDLS peers are registered as CONNECTION_INFRA_STA with peer_addr set to the peer's MAC and nothing else. The proprietary out-of-tree MediaTek driver carries an explicit cfg80211_tdls.c (PTK/TK install paths, etc.) with no in-tree equivalent. Whether the underlying gap is in the firmware HW_ENCAP path or in mt76's missing TDLS-aware setup is unclear from the kernel side; the software-encap path sidesteps it either way. Work around the issue by not advertising SUPPORTS_TX_ENCAP_OFFLOAD and SUPPORTS_RX_DECAP_OFFLOAD in mt792x_init_wiphy(). mac80211 then takes the software 802.11 encap path, which submits already-formed 802.11 frames via a different firmware path that handles all WCIDs correctly, including TDLS peers. mt792x_init_wiphy() is shared with the Connac2 family (mt7921/22/20/02), which uses the same firmware HW_ENCAP path; the disable is applied globally to cover the likely-affected chips. If Connac2 is later confirmed unaffected, the disable can be narrowed with is_mt7925(). Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Cc: stable@vger.kernel.org Signed-off-by: ElXreno Assisted-by: Claude:claude-opus-4-7 bpftrace --- drivers/net/wireless/mediatek/mt76/mt792x_core.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net/wireless/mediatek/mt76/mt792x_core.c index 152cfcca2f90..f9610c6c1597 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c +++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c @@ -681,8 +681,14 @@ int mt792x_init_wiphy(struct ieee80211_hw *hw) ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS); ieee80211_hw_set(hw, HAS_RATE_CONTROL); - ieee80211_hw_set(hw, SUPPORTS_TX_ENCAP_OFFLOAD); - ieee80211_hw_set(hw, SUPPORTS_RX_DECAP_OFFLOAD); + /* HW TX/RX 802.11 encap offload is intentionally NOT advertised: + * the firmware HW_80211_ENCAP path silently drops QoS Data frames + * whose destination WCID is a TDLS direct-link peer, breaking TDLS + * data flow. The mac80211 software encap path submits already-formed + * 802.11 frames, which the firmware handles correctly for all WCIDs. + * Re-add SUPPORTS_TX_ENCAP_OFFLOAD / SUPPORTS_RX_DECAP_OFFLOAD here + * once the firmware HW_ENCAP path is fixed. + */ ieee80211_hw_set(hw, WANT_MONITOR_VIF); ieee80211_hw_set(hw, SUPPORTS_PS); ieee80211_hw_set(hw, SUPPORTS_DYNAMIC_PS); -- 2.53.0