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!
