| Message ID | 20240215-nl80211_fix_akm_suites_endianness-v1-0-57e902632f9d@bootlin.com |
|---|---|
| Headers | show |
| Series | wifi: nl80211/wilc1000: force WLAN_AKM_SUITE_SAE to big endian in NL80211_CMD_EXTERNAL_AUTH | expand |
On 2/15/24 15:13, Alexis Lothoré wrote: > This small series is the follow-up to discussions started around a sparse > warning in wilc1000 driver ([1]) and implements the solution suggested by > Johannes. It moves a historically needed conversion to be32 in nl80211 (in > NL80211_CMD_EXTERNAL_AUTH, specifically on NL80211_ATTR_AKM_SUITES property > _only_ when it is set to WLAN_AKM_SUITE_SAE) The user scenario affected by > this update is a connect process on a WPA3-protected access point with > authentication offloaded to user-space. Two drivers are affected by the > update: wilc1000 and qtnfmac. wilc1000 case is handled by a small > companion patch which also fixes the sparse warning. Adding Claudio Beznea (co-maintainer for WILC), who got lost when I prepared the series, sorry. Also, my mail provider returns error 550 (No Such User Here) for quantenna driver maintainer (<imitsyanko@quantenna.com>, taken from MAINTAINERS). I've seen no recent activity from him on the ML, is he still around ?
Alexis Lothoré <alexis.lothore@bootlin.com> writes: > User-space supplicant (observed at least on wpa_supplicant) historically > parses the NL80211_ATTR_AKM_SUITES from the NL80211_CMD_EXTERNAL_AUTH > message as big endian _only_ when its value is WLAN_AKM_SUITE_SAE, while > processing anything else in host endian. This behavior makes any driver > relying on SAE external auth to switch AKM suite to big endian if it is > WLAN_AKM_SUITE_SAE. A fix bringing compatibility with both endianness > has been brought into wpa_supplicant, however we must keep compatibility > with older versions, while trying to reduce the occurences of this manual > conversion in wireless drivers. > > Add the be32 conversion specifically on WLAN_AKM_SUITE_SAE in nl80211 layer > to keep compatibility with older wpa_supplicant versions. > > Suggested-by: Johannes Berg <johannes@sipsolutions.net> > Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> A pointer to the discussion would be nice to have: Link: https://lore.kernel.org/all/09eeb7d4-c922-45ee-a1ac-59942153dbce@bootlin.com/ I assume Johannes can add that. Alexis, thanks so much for working on this! This has been bugging me for long but never found the time to investigate it.
Kalle Valo <kvalo@kernel.org> writes: > (changing subject) > > Alexis Lothoré <alexis.lothore@bootlin.com> writes: > >> Also, my mail provider returns error 550 (No Such User Here) for quantenna >> driver maintainer (<imitsyanko@quantenna.com>, taken from MAINTAINERS). I've >> seen no recent activity from him on the ML, is he still around ? > > I found a bounce for imitsyanko@quantenna.com from 2022 so I guess it's > time to orphan qtnfmac? > > Also the purelife maintainer Srini Raju (CCed) is bouncing, that's > another candidate to orphan. And confirmed, I just got bounces for both of these maintainers. Patches welcome to orphan these drivers. <srini.raju@purelifi.com>: host purelifi-com.mail.protection.outlook.com[52.101.68.16] said: 550 5.4.1 Recipient address rejected: Access denied. [DB5PEPF00014B8D.eurprd02.prod.outlook.com 2024-02-15T17:07:03.735Z 08DC2C530F4F7910] (in reply to RCPT TO command) <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No Such User Here (in reply to RCPT TO command)
On 2/15/2024 9:21 AM, Kalle Valo wrote: > <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No > Such User Here (in reply to RCPT TO command) Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022 they closed it down[2]. Seems pretty abandoned to me. [1] https://www.eetimes.com/on-semi-to-acquire-wi-fi-chip-vendor-quantenna-for-1-billion/ [2] https://www.bizjournals.com/phoenix/news/2022/09/20/onsemi-close-down-quantenna.html
On 2/15/24 17:58, Kalle Valo wrote: > Alexis Lothoré <alexis.lothore@bootlin.com> writes: > >> User-space supplicant (observed at least on wpa_supplicant) historically >> parses the NL80211_ATTR_AKM_SUITES from the NL80211_CMD_EXTERNAL_AUTH >> message as big endian _only_ when its value is WLAN_AKM_SUITE_SAE, while >> processing anything else in host endian. This behavior makes any driver >> relying on SAE external auth to switch AKM suite to big endian if it is >> WLAN_AKM_SUITE_SAE. A fix bringing compatibility with both endianness >> has been brought into wpa_supplicant, however we must keep compatibility >> with older versions, while trying to reduce the occurences of this manual >> conversion in wireless drivers. >> >> Add the be32 conversion specifically on WLAN_AKM_SUITE_SAE in nl80211 layer >> to keep compatibility with older wpa_supplicant versions. >> >> Suggested-by: Johannes Berg <johannes@sipsolutions.net> >> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> > > A pointer to the discussion would be nice to have: > > Link: https://lore.kernel.org/all/09eeb7d4-c922-45ee-a1ac-59942153dbce@bootlin.com/ > > I assume Johannes can add that. Ah yes, indeed. Johannes, please let me know if you prefer me to resend it with the link in the commit message. > Alexis, thanks so much for working on this! This has been bugging me for > long but never found the time to investigate it. I'm glad to help, especially since I have the corresponding hardware. This warning was on my radar, and your last complaint about remaining sparse warnings in the wireless tree eventually triggered the action :)
Alexis Lothoré <alexis.lothore@bootlin.com> writes: >> Alexis, thanks so much for working on this! This has been bugging me for >> long but never found the time to investigate it. > > I'm glad to help, especially since I have the corresponding hardware. This > warning was on my radar, and your last complaint about remaining sparse warnings > in the wireless tree eventually triggered the action :) Hah, at least there's one person who reads my complaints :) I owe you a beer on this one, if we ever meet please remind me.
Jeff Johnson <quic_jjohnson@quicinc.com> writes: > On 2/15/2024 9:21 AM, Kalle Valo wrote: >> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No >> Such User Here (in reply to RCPT TO command) > > Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022 > they closed it down[2]. Seems pretty abandoned to me. Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe we should just delete the drivers as nobody seems to care about them?
On 2/16/24 01:37, Kalle Valo wrote: > Jeff Johnson <quic_jjohnson@quicinc.com> writes: > >> On 2/15/2024 9:21 AM, Kalle Valo wrote: >>> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No >>> Such User Here (in reply to RCPT TO command) >> Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022 >> they closed it down[2]. Seems pretty abandoned to me. > Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe > we should just delete the drivers as nobody seems to care about them? > (replacing imitsyanko@quantenna.com with my personal email) Hi Kalle, Jeff, that's right, Quantenna division was shutdown by ON. To my knowledge no users of qtnfmac drivers are left after that. I would think removing driver altogether is the right approach. I'm not associated with ON anymore so it's just my personal opinion. CCing Krystal Heaton who I found on ON "contacts" web page (just in case someone from ON wants to comment if removing qtnfmac driver from Linux kernel is a concern).
Igor Mitsyanko <i.mitsyanko@gmail.com> writes: > On 2/16/24 01:37, Kalle Valo wrote: >> Jeff Johnson <quic_jjohnson@quicinc.com> writes: >> >>> On 2/15/2024 9:21 AM, Kalle Valo wrote: >>>> <imitsyanko@quantenna.com>: host mail.quantenna.com[50.87.249.29] said: 550 No >>>> Such User Here (in reply to RCPT TO command) >>> Apparently Quantenna was acquired by ON Semi in 2019[1], and in 2022 >>> they closed it down[2]. Seems pretty abandoned to me. >> Thanks Jeff. I do wonder is anyone even using qtnfmac and plfxlc? Maybe >> we should just delete the drivers as nobody seems to care about them? >> > (replacing imitsyanko@quantenna.com with my personal email) > > Hi Kalle, Jeff, > > that's right, Quantenna division was shutdown by ON. To my knowledge > no users of qtnfmac drivers are left after that. I would think > removing driver altogether is the right approach. I'm not associated > with ON anymore so it's just my personal opinion. > > CCing Krystal Heaton who I found on ON "contacts" web page (just in > case someone from ON wants to comment if removing qtnfmac driver from > Linux kernel is a concern). Sad news but thanks for letting us know. So unless anyone else objects the plan is to remove qtnfmac driver in the near future.
Hi On 2024-02-27, Kalle Valo wrote: > Igor Mitsyanko <i.mitsyanko@gmail.com> writes: > > On 2/16/24 01:37, Kalle Valo wrote: > >> Jeff Johnson <quic_jjohnson@quicinc.com> writes: > >>> On 2/15/2024 9:21 AM, Kalle Valo wrote: [...] > > that's right, Quantenna division was shutdown by ON. To my knowledge > > no users of qtnfmac drivers are left after that. I would think > > removing driver altogether is the right approach. I'm not associated > > with ON anymore so it's just my personal opinion. > > > > CCing Krystal Heaton who I found on ON "contacts" web page (just in > > case someone from ON wants to comment if removing qtnfmac driver from > > Linux kernel is a concern). > > Sad news but thanks for letting us know. So unless anyone else objects > the plan is to remove qtnfmac driver in the near future. In theory, there would be quite a few /potential/ users for qtnfmac and QT3840BC 'Topaz' (QSR1000) on a variety of early 802.11ac routers and APs (particularly on ipq8064 SOCs[0]), but as the required qtnfmac firmware for these chipsets has never been published, there is no wireless support for (the typically 5 GHz-) "Topaz" wlan chipset on those devices at all. The devices are out there (albeit not the most common- or long-lived combination), but they never had wireless support in the first place (first because qtnfmac didn't support QSR1000, after that was rectified[1], because the required firmware for qtnfmac/ QSR1000 has never been published). It's a bit sad that these never got supported. Regards Stefan Lippers-Hollmann -- [0] e.g. Linksys E8350, Linksys E8400, Netgear R7500, ZyXEL NBG6816 (Armor Z1), ZyXEL WAP6806 (Armor X1) (on mt7621) [Disclaimer: I don't own any of these myself, but I regularly see requests for Topaz wireless support on the r7500 and e8350] [1] Tue Oct 16 10:23:58 2018 +0000, qtnfmac: add support for Topaz chipsets e401fa25cfa23df8b17960a656ff11f49facae84
This small series is the follow-up to discussions started around a sparse warning in wilc1000 driver ([1]) and implements the solution suggested by Johannes. It moves a historically needed conversion to be32 in nl80211 (in NL80211_CMD_EXTERNAL_AUTH, specifically on NL80211_ATTR_AKM_SUITES property _only_ when it is set to WLAN_AKM_SUITE_SAE) The user scenario affected by this update is a connect process on a WPA3-protected access point with authentication offloaded to user-space. Two drivers are affected by the update: wilc1000 and qtnfmac. wilc1000 case is handled by a small companion patch which also fixes the sparse warning. For the quantenna driver, I don't really get how it manipulates AKM suites. The only thing it currently does on it before calling nl80211 is a le32_to_cpu. IIUC the raw value (before applying le32_to_cpu) comes from chip/firmware: <interrupt> qtnf_shm_ipc_irq_handler <some callbacks chains> qtnf_pcie_control_rx_callback qtnf_trans_handle_rx_ctl_packet qtnf_trans_event_enqueue => queue skb to processing queue qtnf_event_work_handler <= dequeue corresponding skb to process qtnf_event_process_skb qtnf_event_parse qtnf_event_handle_external_auth cfg80211_external_auth_request => sends NL80211_CMD_EXTERNAL_AUTH There is no cast to big endian on AKM suite at any point in this chain, but there are plenty of leXX_to_cpu, so I assume the chip/its firmware sends its data in little endian. Then, since the be32 conversion is _needed_ with current wpa_supplicant, I wonder if it works at all in current state, so I did not modify it. Or has it been tested with another supplicant (iwd ?) which handles WLAN_AKM_SUITE_SAE differently ? Opinions (and even some testing) are welcome for this driver, since I do not have the corresponding hardware. [1] https://lore.kernel.org/linux-wireless/87a5uatfl1.fsf@kernel.org/ To: Johannes Berg <johannes@sipsolutions.net> Cc: Ajay Singh <ajay.kathat@microchip.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: <linux-wireless@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Cc: Igor Mitsyanko <imitsyanko@quantenna.com> Cc: Sergey Matyukevich <geomatsi@gmail.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> --- Alexis Lothoré (2): wifi: nl80211: force WLAN_AKM_SUITE_SAE in big endian in NL80211_CMD_EXTERNAL_AUTH wifi: wilc1000: remove AKM suite be32 conversion for external auth request drivers/net/wireless/microchip/wilc1000/cfg80211.c | 2 +- net/wireless/nl80211.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 2 deletions(-) --- base-commit: a4c7842e88b0f7d937015e4588ea2a1dec33cf2c change-id: 20240214-nl80211_fix_akm_suites_endianness-2750a5d7da83 Best regards,