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

From: Neal Gompa
Date: Thu Dec 21 2023 - 19:04:05 EST


On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@xxxxxxxxxxxx> 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@xxxxxxxxx>
> >>>>>> Reviewed-by: Neal Gompa <neal@xxxxxxxxx>
> >>>>>
> >>>>> 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



--
真実はいつも一つ!/ Always, there's only one truth!