On Sat, May 25, 2024 at 12:15:22PM +0300, Kalle Valo wrote: > Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> writes: > > > params->crypto.n_akm_suites seems to be limited to two AKM suites. Once > > there are more they will be passed as extra elements of type WLAN_EID_RSN > > or WLAN_EID_VENDOR_SPECIFIC. > > > > This takes some snippets from the downstream vendor driver to parse > > these elements and to set the correct protocol and key_mgmt bits to > > enable the desired key managements algorithms in the hardware. > > > > This patch is not a request for inclusion, more a heads up that there's > > something missing and the question if the approach taken is the right > > one or if there are other preferred ways to fix this issue. > > Please mark patches like this as "[PATCH RFC]", that way we maintainers > know to drop them automatically. Yes, will do. I should have known that. The question I had with this patch is more like whether the approach is fine. I wonder why I have to parse the WLAN_EID_RSN element in driver specific code and why I do not find similar code in other drivers which should suffer from the same problem. Looking deeper at it the Kernel by default only supports two AKM suites. wiphy->max_num_akm_suites is initialized to NL80211_MAX_NR_AKM_SUITES (which is 2). Whenever wpa_supplicant/hostapd specify more AKM suites the suites exceeding 2 are encoded in the WLAN_EID_RSN element and I would expect other drivers to handle this as well. I realized that the Kernel can handle up to 10 AKM suites by setting wiphy->max_num_akm_suites to CFG80211_MAX_NUM_AKM_SUITES and that seems to do the trick as well, at least when I patch wpa_supplicant to actually use this increased number. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
