summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath10k/core.c
diff options
context:
space:
mode:
authorSergey Ryazanov <ryazanov.s.a@gmail.com>2022-05-16 13:26:00 +0300
committerKalle Valo <quic_kvalo@quicinc.com>2022-05-22 15:27:51 +0300
commit70f119fb82af7f7417dc659faf02c91e1f853739 (patch)
treecabb01ed29b83fd489a6581b85f77615a59b226a /drivers/net/wireless/ath/ath10k/core.c
parent2587d5198aa5adcbd8896aae4a2404dc13d48637 (diff)
downloadlinux-70f119fb82af7f7417dc659faf02c91e1f853739.tar.xz
ath10k: htt_tx: do not interpret Eth frames as WiFi
The xmit path for the Ethernet encapsulated frames become more or less usable since d740d8fd2439 ("ath10k: unify tx mode and dispatch"). This change reorganize the xmit path in a manageable way to properly support various tx modes, but misses that the Ethernet encapsulated frame is a special case. We do not have an IEEE 802.11 header at the begining of them. But the HTT Tx handler still interprets first bytes of each frame as an IEEE 802.11 Frame Control field. Than this code was copied by e62ee5c381c5 ("ath10k: Add support for htt_data_tx_desc_64 descriptor") and a2097d6444c3 ("ath10k: htt: High latency TX support") to another handlers. In fact the issue in the high latency (HL) handler was introduced by 83ac260151e7 ("ath10k: add mic bytes for pmf management packet"). Ethernet encapsulated frame tx mode stay unused until 75d85fd9993c ("ath10k: introduce basic tdls functionality") started using it for TDLS frames to avoid key selection issue in some firmwares. Trying to interpret the begining of an Ethernet encapsulated frame as an IEEE 802.11 header was not hurt us noticeably since we need to meet two conditions: (1) xmit should be performed towards a TDLS peer, and (2) the TDLS peer should have a specific OUI part of its MAC address. Looks like that the rareness in TDLS communications of OUIs that can be interpreted as an 802.11 management frame saves users from facing this issue earlier. Improve Ethernet tx mode support in the HTT Tx handler by avoiding interpreting its first bytes as an IEEE 802.11 header. While at it, make the ieee80211_hdr variable local to the code block that is guarded by !is_eth check. In this way, we clarify in which cases a frame can be interpreted as IEEE 802.11, and saves us from similar issues in the future. Credits: this change as part of xmit encapsulation offloading support was originally made by QCA and then submitted for inclusion by John Crispin [1]. But the whole work was not accepted due to the lack of a part for 64-bits descriptors [2]. Zhijun You then pointed this out to me in a reply to my initial RFC patch series. And I made this slightly reworked version that covered all the HTT Tx handler variants. 1. https://lore.kernel.org/all/20191216092207.31032-1-john@phrozen.org/ 2. https://patchwork.kernel.org/project/linux-wireless/patch/20191216092207.31032-1-john@phrozen.org/ Reported-by: Zhijun You <hujy652@gmail.com> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220516032519.29831-3-ryazanov.s.a@gmail.com
Diffstat (limited to 'drivers/net/wireless/ath/ath10k/core.c')
0 files changed, 0 insertions, 0 deletions