FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072 - #955
FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072#955miaoqing-quic wants to merge 1 commit into
Conversation
In MLO connections, ath12k_wifi7_dp_rx_set_link_id_wcn7850() attempts to resolve the IEEE 802.11 link ID for received frames by matching rxcb->peer_id against the link_peer->peer_id entries in dp_peer->link_peers[]. This fails for EAPOL frames because the firmware delivers them via the MLD peer path. In this case, rxcb->peer_id contains an MLD peer ID while link_peer->peer_id contains a link peer ID. The mismatch prevents status->link_valid from being set. When mac80211 receives a data frame with link_valid=0 for an MLO station, it calls link_sta_info_get_bss() with hdr->addr2 to resolve the link ID. If hdr->addr2 contains the AP MLD address rather than a link address, the lookup fails because link_sta_info_get_bss() indexes by link address, and the frame is dropped in __ieee80211_rx_handle_packet(). This is observed on QCC2072 where EAPOL M3 uses the MLD address, deauthenticated (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) Fix this by resolving the link peer using the current operating frequency associated with each link peer. For 6 GHz links, the received frequency corresponds to the operating center frequency, while for other bands it corresponds to the primary channel frequency. Match the received frame against associated links using the appropriate frequency for each band. The frequency-based lookup is used only when exactly one associated link matches the received frequency. If multiple links share the same frequency, the match becomes ambiguous and no link ID is assigned. In that case, leave status->link_valid unset and let mac80211 fall back to its own link resolution logic. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: a2fe9dc ("wifi: ath12k: Fix low MLO RX throughput on WCN7850") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
|
Merge Check Failed: No Change Task Found No associated change tasks found for CR 4612924 on any of the following entities: Entities:
CR: 4612924 Please ensure the CR has a change task associated with at least one of the entities for this branch. |
PR #955 — validate-patchPR: #955
Final Summary
|
PR #955 — checker-log-analyzerPR: #955
Detailed report: Full report
|
In MLO connections, ath12k_wifi7_dp_rx_set_link_id_wcn7850() attempts to resolve the IEEE 802.11 link ID for received frames by matching rxcb->peer_id against the link_peer->peer_id entries in dp_peer->link_peers[].
This fails for EAPOL frames because the firmware delivers them via the MLD peer path. In this case, rxcb->peer_id contains an MLD peer ID while link_peer->peer_id contains a link peer ID. The mismatch prevents status->link_valid from being set.
When mac80211 receives a data frame with link_valid=0 for an MLO station, it calls link_sta_info_get_bss() with hdr->addr2 to resolve the link ID. If hdr->addr2 contains the AP MLD address rather than a link address, the lookup fails because link_sta_info_get_bss() indexes by link address, and the frame is dropped in __ieee80211_rx_handle_packet(). This is observed on QCC2072 where EAPOL M3 uses the MLD address,
deauthenticated (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
Fix this by resolving the link peer using the current operating frequency associated with each link peer.
For 6 GHz links, the received frequency corresponds to the operating center frequency, while for other bands it corresponds to the primary channel frequency. Match the received frame against associated links using the appropriate frequency for each band.
The frequency-based lookup is used only when exactly one associated link matches the received frequency. If multiple links share the same frequency, the match becomes ambiguous and no link ID is assigned. In that case, leave status->link_valid unset and let mac80211 fall back to its own link resolution logic.
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Fixes: a2fe9dc ("wifi: ath12k: Fix low MLO RX throughput on WCN7850")
Link: https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
CRs-Fixed: 4612924