Message-ID: <6b5156cf-bc90-48b5-a5c8-669145f714f4@broadcom.com>
Date: Sun, 24 Dec 2023 10:03:07 +0100
From: Arend van Spriel <arend.vanspriel@...adcom.com>
To: Neal Gompa <neal@...pa.dev>, Marcel Holtmann <marcel@...tmann.org>
Cc: Julian Calaby <julian.calaby@...il.com>, Kalle Valo <kvalo@...nel.org>,
 Hector Martin <marcan@...can.st>, Arend van Spriel <aspriel@...il.com>,
 Franky Lin <franky.lin@...adcom.com>,
 Hante Meuleman <hante.meuleman@...adcom.com>,
 Daniel Berlin <dberlin@...rlin.org>, linux-wireless@...r.kernel.org,
 brcm80211-dev-list.pdl@...adcom.com, SHA-cyfmac-dev-list@...ineon.com,
 linux-kernel@...r.kernel.org, asahi@...ts.linux.dev
Subject: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

On 12/22/2023 1:03 AM, Neal Gompa wrote:
> On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@...tmann.org> wrote:
>>
>> Hi Julian,
>>
>>>>>>>> Using the WSEC command instead of sae_password seems to be the supported
>>>>>>>> mechanism on newer firmware, and also how the brcmdhd driver does it.
>>>>>>>>
>>>>>>>> According to user reports [1], the sae_password codepath doesn't actually
>>>>>>>> work on machines with Cypress chips anyway, so no harm in removing it.
>>>>>>>>
>>>>>>>> This makes WPA3 work with iwd, or with wpa_supplicant pending a support
>>>>>>>> patchset [2].
>>>>>>>>
>>>>>>>> [1] https://rachelbythebay.com/w/2023/11/06/wpa3/
>>>>>>>> [2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html
>>>>>>>>
>>>>>>>> Signed-off-by: Hector Martin <marcan@...can.st>
>>>>>>>> Reviewed-by: Neal Gompa <neal@...pa.dev>
>>>>>>>
>>>>>>> Arend, what do you think?
>>>>>>>
>>>>>>> We recently talked about people testing brcmfmac patches, has anyone else
>>>>>>> tested this?
>>>>>>
>>>>>> Not sure I already replied so maybe I am repeating myself. I would prefer
>>>>>> to keep the Cypress sae_password path as well although it reportedly does
>>>>>> not work. The vendor support in the driver can be used to accommodate for
>>>>>> that. The other option would be to have people with Cypress chipset test
>>>>>> this patch. If that works for both we can consider dropping the
>>>>>> sae_password path.
>>>>>>
>>>>>> Regards,
>>>>>> Arend
>>>>>
>>>>> So, if nobody from Cypress chimes in ever, and nobody cares nor tests
>>>>> Cypress chipsets, are we keeping any and all existing Cypress code-paths
>>>>> as bitrotting code forever and adding gratuitous conditionals every time
>>>>> any functionality needs to change "just in case it breaks Cypress" even
>>>>> though it has been tested compatible on Broadcom chipsets/firmware?
>>>>>
>>>>> Because that's not sustainable long term.
>>>>
>>>> You should look into WEXT just for the fun of it. If it were up to me
>>>> and a bunch of other people that would have been gone decades ago. Maybe
>>>> a bad example if the sae_password is indeed not working, but the Cypress
>>>> chipset is used in RPi3 and RPi4 so there must be a couple of users.
>>>
>>> There are reports that WPA3 is broken on the Cypress chipsets the
>>> Raspberry Pis are using and this patch fixes it:
>>> https://rachelbythebay.com/w/2023/11/06/wpa3/
>>>
>>> Based on that, it appears that all known users of WPA3 capable
>>> hardware with this driver require this fix.
>>
>> the Pis are all using an outdated firmware. In their distro they put the
>> firmware already under the alternates systems, but it just lacks the SAE
>> offload support that is required to make WPA3 work. The linux-firmware
>> version does the trick nicely.
>>
>> I documented what I did to make this work on Pi5 (note that I normally
>> use Fedora on Pi4 and thus never encountered this issue)
>>
>> https://holtmann.dev/enabling-wpa3-on-raspberry-pi/
>>
>> However you need to use iwd and not hope that you get a wpa_supplicant
>> released version that will work.
>>
>> So whole game of wpa_supplicant is vendor specific to the company that
>> provides the driver is also insane, but that is another story. Use iwd
>> and you can most likely have WPA3 support if you have the right firmware.
>>
> 
> wpa_supplicant is perfectly fine if the necessary patches are
> backported, as Fedora has done:
> https://src.fedoraproject.org/rpms/wpa_supplicant/c/99f4bf2096d3976cee01c499d7a30c1376f5f0f7

The brcmfmac firmware has its own 802.11 stack implementation and as 
such it has a SME running in firmware which means the driver only 
implements the NL80211_CMD_CONNECT primitive. Now if the firmware also 
has in-driver supplicant (*-idsup-*) supporting SAE (*-sae-*) it can be 
offloaded. That is what Cypress went with at least for upstream. For 
firmware without these in the firmware target string the driver needs to 
implement support for NL80211_CMD_EXTERNAL_AUTH, which is what we opted 
for in Broadcom BCA (or WCC-Access as we call it these days). So I don't 
think it is a fair assessment to call the wpa_supplicant implementation 
vendor specific.

Regards,
Arend

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)

Powered by blists - more mailing lists