Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

[Arend van Spriel <arend.vanspriel@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 4197 bytes --]

On 12/22/2023 1:03 AM, Neal Gompa wrote:
> On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@holtmann.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@marcan.st>
>>>>>>>> Reviewed-by: Neal Gompa <neal@gompa.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

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]