Am 14.04.24 um 13:32 schrieb Bitterblue Smith:
On 14/03/2024 18:48, Martin Kaistra wrote:
In order to connect to networks which require 802.11w, add the
MFP_CAPABLE flag and let mac80211 do the actual crypto in software.
When a robust management frames is received, rx_dec->swdec is not set,
even though the HW did not decrypt it. Extend the check and don't set
RX_FLAG_DECRYPTED for these frames in order to use SW decryption.
Signed-off-by: Martin Kaistra <martin.kaistra@xxxxxxxxxxxxx>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 4a49f8f9d80f2..870bd952f5902 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6473,7 +6473,9 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
- if (!rx_desc->swdec)
+ if (!rx_desc->swdec &&
+ !(_ieee80211_is_robust_mgmt_frame(hdr) &&
+ ieee80211_has_protected(hdr->frame_control)))
rx_status->flag |= RX_FLAG_DECRYPTED;
if (rx_desc->crc32)
rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
@@ -6578,7 +6580,9 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
- if (!rx_desc->swdec)
+ if (!rx_desc->swdec &&
+ !(_ieee80211_is_robust_mgmt_frame(hdr) &&
+ ieee80211_has_protected(hdr->frame_control)))
rx_status->flag |= RX_FLAG_DECRYPTED;
if (rx_desc->crc32)
rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
@@ -7998,6 +8002,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
ieee80211_hw_set(hw, HAS_RATE_CONTROL);
ieee80211_hw_set(hw, SUPPORT_FAST_XMIT);
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
+ ieee80211_hw_set(hw, MFP_CAPABLE);
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
I ran into this problem recently with rtl8192du:
https://lore.kernel.org/linux-wireless/ed12ec17-ae6e-45fa-a72f-23e0a34654da@xxxxxxxxx/
Does the same fix work for you in rtl8xxxu? Checking the "security"
field of the RX descriptor is simpler than calling two functions.
Sorry to bother you when the patch is already applied.
Thanks for the hint. I tried to do something similar to what has been done in
other rtlwifi drivers and missed the solution in rtw88, which is probably better:
rtlwifi/rtl8188ee/trx.c
rtlwifi/rtl8192ce/trx.c
rtlwifi/rtl8192ee/trx.c
rtlwifi/rtl8192se/trx.c
rtlwifi/rtl8723ae/trx.c
rtlwifi/rtl8723be/trx.c
rtlwifi/rtl8821ae/trx.c
Shouldn't it be changed in these locations as well?
I will do a test for rtl8xxxu and if it is successful send a new patch.
Also, won't you send the patch to the stable tree?
The rtl8xxxu driver previously did not have the MFP_CAPABLE flag set. As I am
adding new functionality (support for WPA3), I don't think this should go to stable.
