> From: Brian Norris <briannorris@xxxxxxxxxxxx> > Sent: Friday, April 26, 2024 9:09 AM > To: David Lin <yu-hao.lin@xxxxxxx> > Cc: Marcel Holtmann <marcel@xxxxxxxxxxxx>; > linux-wireless@xxxxxxxxxxxxxxx; LKML <linux-kernel@xxxxxxxxxxxxxxx>; Kalle > Valo <kvalo@xxxxxxxxxx>; francesco@xxxxxxxxxx; Pete Hsieh > <tsung-hsien.hsieh@xxxxxxx>; rafael.beims <rafael.beims@xxxxxxxxxxx>; > Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx> > Subject: Re: [EXT] [PATCH v10 0/2] wifi: mwifiex: add code to support host > mlme > > Hi David, > > On Wed, Apr 24, 2024 at 7:40 PM David Lin <yu-hao.lin@xxxxxxx> wrote: > > > From: Marcel Holtmann <marcel@xxxxxxxxxxxx> > > > > > > Hi David, > > > > > > > Johannes agreed that cfg80211 is the correct way for the > > > > development of mwifiex > > > > (mac80211 can't offload association process to driver/FW). > > > > > > that was never my question here. > > > > > > > This is previous topic discussed with Johannes to confirm cfg80211 is > correct decision for NXP FW. > > To be clear: external_auth() is a cfg80211 feature. So this part of your > response still isn't very relevant. > Sorry I mean external_auth() is another way to let wpa_supplicant handle SAE, but it doesn’t necessarily mean we have to use external_auth for SAE. Our previous discussion has covered how current patch implemented using cfg80211 is valid. > > > > This patch is used to fully leverage SME of wpa_supplicant and > > > > hostapd > > > which can complete the missing WPA3 feature of mwifiex. > > > > The patch series had been reviewed and discussed. It looks like > > > > there is no > > > more comments for patch v10. > > > > I wonder can patch v10 be accepted by you? > > > > > > If your hardware is a FullMac hardware then what is the point in now > > > separating auth/assoc out. Is this done just for WPA3 or also for > WPA2/WPA1. > > > > Yes. Our FW can's support WPA3, so this patch is used to hook > > separating auth/assoc to leverage SME of wpa_supplicant and hostapd. > > WPA2 is also handled by SME of wpa_supplicant and hostapd. > > > > > Are you no longer a FullMac hardware? > > > > You can check previous discussion with Johannes, FW still needs to > > involve association process, so mac80211 is not suitable for NXP FW. > > For the record, that's the v9 thread, around here: > > https://lore.ke/ > rnel.org%2Fall%2F7a08dbcaded25ec0d32865647d571afbd66062fe.camel%40 > sipsolutions.net%2F&data=05%7C02%7Cyu-hao.lin%40nxp.com%7Cd5f6edc4 > 9f8b45171e8508dc658d744f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C0%7C638496905433159887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=eRuUVAXH%2B%2B27LeOo%2BHmGz%2Byc1QbuWl8f%2BbtSkE > 6SxUg%3D&reserved=0 > > > > You keep saying that you just want to support WPA3 and if previously > > > the HW worked as FullMac hardware, then external_auth should be the > > > way to go for having SAE handled by wpa_supplicant (or iwd for that > matter). > > > > Although external_auth is one way to support SAE, but we think hook > > separating auth/assoc will be the better way to resolve this issue. In > > this way, offloading SME to wpa_supplicant/hostpad will let any future > > changes be easy to support (we only need to check if there is anything that > we should do when converting association request to the association > command supported by FW). > > Perhaps I'm missing something (very likely), but I don't immediately see > much difference (with respect to your FW API, and future > extensibility) between external_auth() and your current solution (of > intercepting auth()/assoc() and constructing your own AUTH frames). It > mostly just means the AUTH mgmt frames will be coming in via > NL80211_CMD_FRAME instead of being manually constructed within your > .auth() hook. The external_auth() approach actually looks *more* natural > than your current solution. > > How exactly does your solution make "future changes [easier] to support > [than with external_auth]"? Do you not trust that wpa_supplicant will > provide exactly the right NL80211_CMD_FRAME content you're looking for, > and you need to tweak it to make your firmware happy? You're talking in > extreme generality, which doesn't make it easy for me (and presumably > Marcel) to understand why you're choosing one solution and rejecting > another preexisting one. 1. The process of external_auth should be as follows: a. cfg80211_ops.connect() is called to establish connection with remote AP. b. If authentication is not WLAN_AUTH_SAE, FW will process authentication/association and reply connection result to cfg80211. c. If authentication is WLAN_AUTH_SAE, FW should notify driver to call cfg80211_external_auth_request() to offload authentication to wpa_supplicant. d. FW will wait for authentication result passed by cfg80211_ops.external_auth() to decide if association should be processed with remote AP for the original connection request and reply connection result to cfg80211. NXP FW only supports association with or without authentication, it can't support external_auth. 2. Hook separating auth/assoc will offload SME to wpa_supplicant completely. Driver/FW don't need to involve the process of authentication just like external_auth did. There is no effort for driver/FW to support any future modifications of authentication process. David > > > > Now if you are fully embracing to auth/assoc and we can remove the > > > support for the connect ops, then lets do it. However I don’t see > > > anything properly described in the commit message. You keep saying > > > WPA3 support and nothing else explain what the new Key V2 API of the > firmware would do. > > > > We give a flag to let user to decide to use connect ops or separating > > auth/assoc. We will remove connect ops for our new nxpwifi driver. New > key V2 API supports more key solutions. > > To add to this: AFAIK, you don't even have "v2 API" firmware published for > all chips that mwifiex currently supports, so even if we wanted to completely > convert this driver, we can't do that today. > > > Brian
