search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.21k stars 5.03k forks source link

Wi-Fi Protected Access 3 (WPA3) support #4718

Open ghost opened 3 years ago

ghost commented 3 years ago

I bought a Raspberry Pi Zero 2 W and apparently it does not support my home wifi which uses WPA3.

I excepted that to be the case, since on Debian usually works just fine, and this device is a new release.

It should be at last officialy stated somewhere that is not supported. I basically bought something I can't use.

Notice that WPA3 is not anymore a theory, many commercial routers now ship with it in mixed mode or add that through firmware update.

Side note: actually run just fine on common operating systems from Windows to Android, including Linux if you have no firmware issues.

pelwell commented 3 years ago

Which AP is this that doesn't support WPA2? It seems a bit premature.

kroon040 commented 3 years ago

Is wpa3 possible with debian bullseye with Pi zero w2?

pelwell commented 3 years ago

No Raspberry Pi currently supports WPA3.

kroon040 commented 3 years ago

So the RPI 3 and 4 supports WPA3 and the RPI Zero 2 not?

JamesH65 commented 3 years ago

"No Raspberry Pi supports WPA3"

As in, none of the Raspberry Pi's with wireless support WPA3.

jfargen commented 2 years ago

@JamesH65 is this because wpa_supplicant version which supports WPA3 is 2:2.9-4, but the wpa_supplicant version available on Raspberry Pi 10.11 is 2.8-devel. Or will it require a kernel driver update from Broadcom? Or a new Wifi chipset?

JamesH65 commented 2 years ago

I believe it will need at minimum new firmware, quite possibly a new chip.

JsBergbau commented 2 years ago

According to https://forum.openwrt.org/t/wpa3-support-in-openwrt/10554/144 there is no special hardware support needed for WPA3 with OpenWRT devices. So when you can create an access point with WPA3 encryption in software, than it should also be possible to implement the client solely in software. Would also be very glad when Raspberry PI Zero W and Zero 2W support WPA3.

somerando905 commented 2 years ago

Connecting to a WPA3-Personal network works fine for me with a Pi 3 Model B when I use iwd. I recently bought a Pi Zero 2 W thinking it would behave similarly since supposedly the wifi hardware is almost identical, but unfortunately that's not the case. Same kernel/driver, same network, but it fails to connect.

iw reports support for the SAE_OFFLOAD extended feature among other things on the 3b, not on the 02w though. So that's one obvious difference. Looking at the brcmfmac driver, it seems that that feature flag gets set if the firmware claims support.

The 02w wifi firmware then looks rather "beta" to me, going by the version string:

BCM43430/2 wl0: Oct  9 2020 14:44:32 version 9.88.4.65 (test) (f149b32@shgit)  (r679549) FWID 01-f40f3270

I suppose it's incomplete? Are there any plans to release an updated firmware in the foreseeable future?

jetflux commented 2 years ago

Why can't the raspberry pi broadcom wifi chips support WPA3 ?!? I Tried many wifi dongles from cheapest realtek to atheros and such with wpa_supplicant 2.9+ they all work with WPA3, but broadcom raspberry pi's dont. I hope the new raspberry pi's comming will dump broadcom for something better....

somerando905 commented 2 years ago

Are there any plans to release an updated firmware in the foreseeable future?

I take the lack of a response to mean "no."

That's too bad. But I noticed there are commits in the firmware repo referencing a new Zero 2 W revision with a different wifi chipset. Hope you get those wifi issues sorted out, it's a nice device otherwise. Cheers

schildbach commented 2 years ago

I'm also longing for my Raspi Zero 2 W to support WPA3. I thought that's a matter of course these days.

taylorkline commented 2 years ago

No issue on my end:

/etc/wpa_supplicant/wpa_supplicant.conf:

update_config=1

network={
 ssid="ssid"
 key_mgmt=WPA-PSK-SHA256
 psk=psk
 ieee80211w=2
}
jeffsf commented 2 years ago

Fails on a mixed WPA2/WPA3 or a pure WAP3 network against OpenWrt HEAD as of late May 2022. hostapd reports

Mon Jun 13 12:49:46 2022 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH e4:5f:01:aa:bb:cc

repeatedly. AP does not have any issues with macOS or iOS devices on the same VAP.

BennyE commented 2 years ago

@taylorkline - This configuration example is a step in the right direction, but it is not WPA3-Personal. WPA3-Personal uses Simultaneous Authentication of Equals (SAE) as key_mgmt and requires Protected Management Frames (PMF) aka Management Frame Protection (MFP) as in your example (PMF/MFP is standardised via IEEE 802.11w and mandatory in Wi-Fi 6 certification (as WPA3 is mandatory, which requires 802.11w support)). Thanks for sharing!

In my opinion, 802.11w is one of the most important elements to secure the network (clients) against DoS-type attacks (de-assoc/de-auth-attack) - often ESP32-based as previously mentioned in this (or other) threads. (This is also what I tell my partners/customers)

Here is a (validated) WPA3 configuration for wpa_supplicant:

network={
    disabled=0
    ssid="WPA3"
    proto=RSN
    key_mgmt=SAE
    sae_password="very-secure-P4ssw0rd!"
    ieee80211w=2
}

grafik

@JamesH65

I believe it will need at minimum new firmware, quite possibly a new chip.

Fortunately it (often) doesn't require new hardware, at least not for Pi3B+/Pi4. I haven't tried on Pi Zero - subject to be tested.

Infineon (Ex-Broadcom => Ex-Cypress) issues patches against 5.10.9 on their website/community: https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2022-05-11/td-p/353009 (the latest)

There are multiple elements to take into consideration:

  1. Do you want to be a Wi-Fi client (wpa_supplicant) or
  2. Do you want to be a Wi-Fi AP (hostapd)

I've looked at the perspective of being a Wi-Fi client (wpa_supplicant), as I'm in the (comfortable and much appreciated) position to have plenty of Stellar Wireless APs around.

Here is how to make WPA3(-Personal) work:

Edit:

schildbach commented 2 years ago

I've got devices ~10 and 20 years old, and running Ubuntu on them enables WPA3 out of the box. So I somehow doubt we need a new chip on the Raspi for WPA3.

taylorkline commented 2 years ago

@BennyE I followed the Arch Wiki instructions for connecting to a mixed WPA2 / WPA3 AP.

Are these instructions incorrect, then?

jeffsf commented 2 years ago

Just the wrong ones for connecting with SAE https://wiki.archlinux.org/title/wpa_supplicant#Connections_to_pure_WPA3-SAE_access_points

BennyE commented 2 years ago

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command, just replacing the Infineon/Cypress Firmware (without the corresponding Kernel with Infineon/Cypress Patches) will not give you this output. Note that, while the output of iw list lacks the Cipher suite 00-0f-ac:8, it can still use the SAE/SHA-256 Auth-Key-Management (AKM) if the proper wpa_supplicant is used (v2.10 with defconfig -> .config) - the shipped version (v2.9) didn't work for me.

aannenko commented 2 years ago

For me connecting at least to a mixed WPA2/WPA3 network would already be a win! For now none of the wpa_supplicant.conf configurations let me do a proper headless setup and I always have to connect a monitor and a keyboard my Pi 3B+ with bullseye and then fill /etc/network/interfaces with the following to connect it to my WiFi:

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
    wpa-ssid "NETWORK_NAME"
    wpa-psk "NETWORK_PASSWORD"

To be more specific, the following wpa_supplicant.conf does not connect the Pi to my WiFi:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
country=CZ
update_config=1

network={
    ssid="ssid"
    psk="pass"
    key_mgmt=WPA-PSK-SHA256
    ieee80211w=2
}

The same is true for all variations with or without key_mgmt=WPA-PSK, ieee80211=1, ieee80211=2, proto=RSN, key_mgmt=SAE, sae_password="pass", etc.

Do you guys know if there's a way to construct wpa_supplicant.conf from a manually connected WiFi?

dilyanpalauzov commented 2 years ago

On Raspberry Pi 3 Model B Rev 1.2 (as communicated by /proc/cpuinfo) iw list does not print “Device supports SAE with AUTHENTICATE command”.

BennyE commented 2 years ago

On Raspberry Pi 3 Model B Rev 1.2 (as communicated by /proc/cpuinfo) iw list does not print “Device supports SAE with AUTHENTICATE command”.

It will not display this unless you run a patched kernel + latest Cypress/Infineon firmware (April'22 as of this writing).

kelnos commented 2 years ago

I'm having the same issue as @aannenko -- my Pi3 won't even connect to a WPA2/WPA3 mixed-mode network.

herrernst commented 2 years ago

My RPi 3 connected again to my new WPA2/WPA3 mixed network (OpenWRT) after adding key_mgmt=WPA-PSK-SHA256 and ieee80211w=2 to the WPA config, also mentioned here: https://github.com/raspberrypi/linux/issues/4976#issuecomment-1146555337 Still expected that it would work automatically, didn't have to change anything on my Apple devices.

masterxq commented 2 years ago

Any progress on this?

blockfeed commented 2 years ago

I have a similar configuration as @herrernst, WPA2/WPA3 mixed in OpenWRT. The changes in this comment were the proper combination to get my Pi3 online.

paulfertser commented 2 years ago

No issue on my end:

/etc/wpa_supplicant/wpa_supplicant.conf:

update_config=1

network={
 ssid="ssid"
 key_mgmt=WPA-PSK-SHA256
 psk=psk
 ieee80211w=2
}

WPA-PSK-SHA256 (00-0f-ac:6) isn't supported by WPA3-Personal only mode, see the official WPA3 Specification. So what you got working there is WPA2/RSN with 802.11w MFPR with stronger SHA256-based (but not SAE) AKM.

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command, just replacing the Infineon/Cypress Firmware (without the corresponding Kernel with Infineon/Cypress Patches) will not give you this output. Note that, while the output of iw list lacks the Cipher suite 00-0f-ac:8, it can still use the SAE/SHA-256 Auth-Key-Management (AKM) if the proper wpa_supplicant is used (v2.10 with defconfig -> .config)

I've read the relevant source codes and came to the conclusion that * [ SAE_OFFLOAD ]: SAE offload support in iw phy output is enough, the relevant brcmfmac support was introduced in Linux v5.4-rc1-87-g3b1e0a7bdfee and later a regression for WPA/RSN network fixed in v5.7-rc4-1314-gb2fe11f07773. The Cypress firmware from the Linux firmware git tree is enough, I'm testing with Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2 on AP6255 module. That said, neither wpa_supplicant v2.10 nor git master support NL80211_ATTR_SAE_PASSWORD attribute for the CMD_CONNECT so this feature isn't available with any wpa_supplicant version. However, iwd knows how to do that since version 1.13, and I confirm I'm able to use my WPA3-PSK-only AP with this combination (almost-vanilla Linux (just with few unrelated Debian patches, nothing from broadcom), firmware from Linux firmware tree, vanilla iwd), despite 00-0f-ac:8 AKM not listed in the supported ciphers.

paulfertser commented 2 years ago

In my previous comment I forgot to add: The output of iw list needs to tell you Device supports SAE with AUTHENTICATE command

@BennyE , I see this corresponds to NL80211_FEATURE_SAE wiphy feature, and only qtnfmac upstream driver currently advertises it. Do you know if the corresponding brcmfmac patch was ever submitted upstream? Can you share a patchwork link to it please? I think I can probably imagine how wpa_supplicant can work with that. In the mean time it seems like using iwd without any additional kernel patches or tricks is a sensible solution for those needing SAE support.

antanasbruzas commented 1 year ago

What is the status with WPA3 and pi zero 2? Still not working in 2023?

pelwell commented 1 year ago

We're not taking the random collection of hundreds of replacement driver source files (not patches) from Infineon for an older kernel, working out what needs to be updated, then applying it to our tree. They've been asked to use Git for software releases, but so far nothing.

paulfertser commented 1 year ago

What is the status with WPA3 and pi zero 2? Still not working in 2023?

I wouldn't call fully upstream support without any tweaks or tricks "not working" at all. Can you confirm you tried iwd instead of wpa_supplicant and it didn't work for you?

paulfertser commented 1 year ago

We're not taking the random collection of hundreds of replacement driver source files (not patches) from Infineon for an older kernel, working out what needs to be updated, then applying it to our tree. They've been asked to use Git for software releases, but so far nothing.

Infineon could go to hell, you do not need them to implement in wpa_supplicant support for the part of nl80211 that is already provided by upstream kernel and is known to be working with alternative userspace stack, it doesn't look like a hard job at all, and certainly not something requiring support from a silicon vendor. And of course if you offer it to hostap maintainers you should be able to upstream that change rather quiclky.

pelwell commented 1 year ago

You seem to know more about this area than I do - what is it that needs to be done?

paulfertser commented 1 year ago

You seem to know more about this area than I do - what is it that needs to be done?

Basically, something similar to https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=b17f27f04dd09cfe753ff59d1540798ac5de89dd needs to be added to https://w1.fi/cgit/hostap/tree/src/drivers/driver_nl80211.c#n6990 so that in certain cases CMD_CONNECT command would be given a NL80211_ATTR_SAE_PASSWORD attribute.

It might be not exactly trivial as hostap has internal architecture very different from iwd but I would expect it to be doable with a bit of motivation and testing, and then one might hope the upstream would help to iron out the edge cases.

Seems to be a reasonable task for an intern who likes C, especially since there's an easy way to make side-by-side comparisons with an already established implementation.

pelwell commented 1 year ago

Thank you - I'll take a look.

meop commented 1 year ago

I am still a bit confused after reading all these comments. By default, on the Arch or Ubuntu aarch64 distributions for Raspberry Pi 4b, the iw phy command does not find any SAE related features. They are running Linux 6.2 or greater. Does the build of the kernel for the official, Debian-based Raspberry Pi OS distribution for Raspberry Pi 4b, contain patches to the vanilla kernel/driver that add in SAE support? The bundled firmware for BCM4345/6, as reported by dmesg, does seem to already be at a higher version than the reported version in an earlier comment where WPA3-Personal with SAE apparently worked, so I am not sure if any extra Infineon/Cypress/Broadcom firmware is actually still needed. Also, it is not quite clear if the kernel is pulling firmware from /lib/firmware/brcm or /lib/firmware/cypress, but based on the chipset name, it would seem from files in /lib/firmware/brcm, rather than using any Cypress files. Thank you for any clarifications.

paulfertser commented 1 year ago

aarch64 distributions for Raspberry Pi 4b, the iw phy command does not find any SAE related features

I do not know about any special distributions (and why they might be needed for an SBC), on another board (firefly rk3288) with upstream kernel I'm getting:

    Supported extended features:
        * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
        * [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
        * [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode
        * [ DFS_OFFLOAD ]: DFS offload
        * [ SAE_OFFLOAD ]: SAE offload support
        * [ 4WAY_HANDSHAKE_AP_PSK ]: AP mode PSK offload support
        * [ SAE_OFFLOAD_AP ]: AP mode SAE authentication offload support

According to the kernel source code this feature is reported when brcmfmac talks to the firmware that supports "sae".

Does the build of the kernel for the official, Debian-based Raspberry Pi OS distribution for Raspberry Pi 4b, contain patches to the vanilla kernel/driver that add in SAE support?

That's the point, no patches are needed, vanilla upstream kernel supports it.

The bundled firmware for BCM4345/6, as reported by dmesg, does seem to already be at a higher version

[ 15.141709] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2

Also notice how this information directly from the firmware blob mentions sae:

$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n2
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2
DVID 01-1fda2915

And what's your version?

Also, it is not quite clear if the kernel is pulling firmware from /lib/firmware/brcm or /lib/firmware/cypress, but based on the chipset name, it would seem from files in /lib/firmware/brcm, rather than using any Cypress files. Thank you for any clarifications.

Generic way to see that would be modinfo -F firmware brcmfmac but when you're running on hardware you can check dmesg and see what exactly the kernel is loading, e.g.

[   14.950113] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
BennyE commented 1 year ago

Hi @meop,

The Firmware in /lib/firmware/brcm links to /lib/firmware/cypress. WPA3-Personal/SAE required the updated Cypress firmware as well as patches to wpa_supplicant and kernel to work (as detailed in https://github.com/raspberrypi/linux/issues/4718#issuecomment-1155509563). The setup is overall fragile, as there is no official support and any update of components (e.g. updated firmware via apt repository) will install/distribute a firmware that doesn't work for this mission. To me this was more a laboratory setup and I wonder why BRCM/Cypress, now Infineon wouldn't "simply" upstream their contributions so that those custom patches are no longer needed and everybody wins.

paulfertser commented 1 year ago

Hi @BennyE, I think I provided clear information, with references to the source code and specific commits so that anyone can easily verify.

My statement is that:

  1. Current firmware as available from git.kernel.org firmware repository supports SAE (verify by doing strings and checking presence of the sae option)
  2. Current kernel as available from git.kernel.org supports the feature needed to make use of it (verify by reading the commits I mentioned earlier)
  3. Current iwd version supports this feature (verify by reading the source code I mentioned earlier)

This is all upstream, without any tricks or tweaks. Can you please point to a specific error in what I'm saying?

BennyE commented 1 year ago

I haven't replied to you @paulfertser and didn't mean to challenge anything you said. I appreciate that progress has been made on this topic.

meop commented 1 year ago

Hi @paulfertser, thanks for replying. While I certainly do not doubt that you have a working WPA3 solution using unpatched software on your Broadcom 43455 chip, as evidenced by your posts, this is not the case for me, nor I think @BennyE either.

Thanks @BennyE for pointing out that the brcm firmware files are really just symlinks to the cypress ones.

When I say distributions for Raspberry Pi 4, I mean that Arch, Ubuntu, Raspberry Pi OS, are all creating two releases for Raspberry Pi 4: ARMv7 and AArch64. Arch and Ubuntu are copying what Raspberry Pi OS is doing, which is bundling together several proprietary driver/firmware blobs and kernel patches for the ARMv7 release, while trying to minimize this for the AArch64 release, instead relying more on upstream/vanilla software.

This is what I get on latest Ubuntu for Raspberry Pi 4:

root@ubuntu:~# iw phy | grep -i sae root@ubuntu:~# uname -a Linux ubuntu 6.2.0-1010-raspi #12-Ubuntu SMP PREEMPT Tue Jul 18 10:01:14 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux root@ubuntu:~# dmesg | grep BCM4345 [ 16.196739] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 16.472780] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60 root@ubuntu:~# ls -ali /lib/firmware/brcm/brcmfmac43455-sdio.bin 6684 lrwxrwxrwx 1 root root 31 Mar 7 15:33 /lib/firmware/brcm/brcmfmac43455-sdio.bin -> ../cypress/cyfmac43455-sdio.bin root@ubuntu:~# strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60 DVID 01-9b7a7032

Here is a link to the latest release of patches and prebuilt binaries from Infineon

This, and their last public release, are known to:

  1. be missing prebuilt firmware for 43455, although Infineon had said they would be providing this month
  2. not support Linux 6.x, as the patches are backports for 5.x and older kernels

So it is not really clear to me how these distros are creating their AArch64 releases, with some working version of the Cypress firmware, for Linux 6.2, but seemingly lacking WPA3 SAE support.

paulfertser commented 1 year ago

strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60 DVID 01-9b7a7032`

So it's clear this particular firmware binary wasn't compiled with sae support.

Why do not you just try firmware from upstream repo:

$ wget -q -O- https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/cypress/cyfmac43455-sdio.bin | strings | tail -n2
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2
DVID 01-1fda2915

(and clm_blob from there too)

NB: rename the firmware binary file to match your kernel's expectations, reboot, check dmesg and iw phy, it should get SAE_OFFLOAD feature; make sure you're using iwd (not wpa_supplicant).

paulfertser commented 1 year ago

Here's a short overview regarding current situation with Infineon: https://social.treehouse.systems/@marcan/110891279747722005 , https://social.treehouse.systems/@marcan/110891320579234923 . To sum up, they simply do not care at all, do not expect any real improvements from their side.

meop commented 1 year ago

Thanks @paulfertser, your suggestion worked!

Not sure what clm_blob refers to.

Following all the symlinks leads back to the real file being in cypress firmware directory.

Here are my steps:

wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/cypress/cyfmac43455-sdio.bin mv /lib/firmware/cypress/cyfmac43455-sdio-standard.bin /lib/firmware/cypress/cyfmac43455-sdio-standard.bin.orig cp cyfmac43455-sdio.bin /lib/firmware/cypress/cyfmac43455-sdio-standard.bin reboot iw phy | grep -i sae * [ SAE_OFFLOAD ]: SAE offload support * [ SAE_OFFLOAD_AP ]: AP mode SAE authentication offload support

Then install iwd, enable and start its systemd service, and use iwctl to connect to a WPA3-Personal SSID, which this time prompts for the passkey! Add some entries in /etc/systemd/network for systemd-networkd to use to set DHCP for wlan0, and good to go!

Seems like whatever way the vanilla kernel and firmware is built must include at least a good subset of the features/patches Infineon is providing for earlier kernels already built-in, but perhaps still not all? Otherwise it would not matter what Infineon's position on upstreaming their patches is, if the patches are no longer adding much value.

I still wonder what causes the discrepancy between how Raspberry Pi 4 distributions are building the Cypress firmware, vs how upstream is building it:

root@ubuntu:/lib/firmware/cypress# strings cyfmac43455-sdio-standard.bin.orig | tail -n2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60 DVID 01-9b7a7032 root@ubuntu:/lib/firmware/cypress# strings cyfmac43455-sdio-standard.bin | tail -n2 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2 DVID 01-1fda2915

paulfertser commented 1 year ago

Thanks @paulfertser, your suggestion worked!

Yay, glad to hear!

Not sure what clm_blog refers to.

clm_blob is the other binary file that comes as part of the broadcom firmware, I just wasn't sure if the one you already had was compatible with the firmware from git.kernel.org .

Here are my steps: ...

Thank you for sharing, explicit instructions like that might help other users.

I still wonder what causes the discrepancy between how Raspberry Pi 4 distributions are building the Cypress firmware, vs how upstream is building it:

Neither is building the firmware binaries. You can see in git commit it was sent directly by someone from Infineon: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress/cyfmac43455-sdio.bin?id=f97e316775237ca5d46a4bc0614a3073ebec5a9e . Those distributions you tried apparently downloaded the firmware from somewhere else (but again, that other place got the binary from Infineon too). I suggest you contact their maintainers and ask them about the rationale.

0d0a commented 1 year ago

Did NOT work on my pi400 …the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 15 Aug 2023, at 20:15, Paul Fertser @.***> wrote:

Thanks @paulfertser, your suggestion worked!

Yay, glad to hear!

Not sure what clm_blog refers to.

clm_blob is the other binary file that comes as part of the broadcom firmware, I just wasn't sure if the one you already had was compatible with the firmware from git.kernel.org .

Here are my steps: ...

Thank you for sharing, explicit instructions like that might help other users.

I still wonder what causes the discrepancy between how Raspberry Pi 4 distributions are building the Cypress firmware, vs how upstream is building it:

Neither is building the firmware binaries. You can see in git commit it was sent directly by someone from Infineon: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress/cyfmac43455-sdio.bin?id=f97e316775237ca5d46a4bc0614a3073ebec5a9e . Those distributions you tried apparently downloaded the firmware from somewhere else (but again, that other place got the binary from Infineon too). I suggest you contact their maintainers and ask them about the rationale.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

paulfertser commented 1 year ago

Did NOT work on my pi400

Show your full dmesg, the output from strings | tail -n2 to see the firmware options for the file in question, and iw phy output.

Arseney300 commented 1 year ago

I have rpi4: Raspberry Pi 4 Model B Rev 1.2 My firmware: strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n 2

43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.221 (3a6d3a0 CY) CRC: 8f977704 Date: Fri 2020-09-18 02:30:48 PDT Ucode Ver: 1043.2156 FWID 01-bbd9282b DVID 01-3699bb4d from package dpkg -S /lib/firmware/brcm/brcmfmac43455-sdio.bin firmware-brcm80211: /lib/firmware/brcm/brcmfmac43455-sdio.bin

I have router mercusys mr90x, that have WPA3-personal And when i set up WiFi with WPA3-personal with no-auto channel and no-auto channel-width, i can connect to this WiFi from my rpi through iwctl without any problems.

herrernst commented 1 year ago

Why does the Raspberry Pi foundation sell devices with such crappy WiFi drivers? Isn't there anybody working for RPi foundation who can upstream the required changes?

0d0a commented 1 year ago

Totally agree with you HerrErnst!the white rider(Het leuke van ... is weten op reis te zijn; geboren te Vught, opgegroeid in Amsterdam en gezworven door Eurazië…)On 21 Nov 2023, at 20:27, herrernst @.***> wrote: Why does the Raspberry Pi foundation sell devices with such crappy WiFi drivers? Isn't there anybody working for RPi foundation who can upstream the required changes?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>