Raspberry Pi Zero 2 W: BCM43430/2 firmware does not support 4-way handshake offloading #23
Comments
|
Thanks for collating the significant details in one place. A ticket has been opened with Synaptics. |
|
Thanks, Phil! I appreciate it. |
|
@pelwell In the meanwhile, do you have information how we can identify Zero 2 W with each chip so we can document compatibility? |
|
The chips are featureless and under the metal cap of the module so there is no visible difference, and the firmware doesn't know - the board revisions are identical; only the kernel can tell after probing the SDIO bus when booting. The best way to tell which version you have to is to boot it up and type: If the output includes |
|
Synaptics have given us a trial firmware. It appears to make the right noises: The version message at boot is: You will have to rename the firmware when you install it, but I don't think you'll struggle with that... https://drive.google.com/file/d/1_q2aXxBV5PTUSVAE2crt4uqfjbN9ebN3/view?usp=sharing |
|
Thanks for relaying the trial firmware! I have just verified it on my Raspberry Pi Zero 2 W, and it indeed works! I can now connect to encrypted WiFi, too. This is great news. Thanks so much for your help! |
|
There should be an official release next week. |
|
@pelwell would you expect Synaptics to finally make such release in upstream linux-firmware, or would that be only from Raspberry Pi Ltd at this stage? |
|
I don't expect this release to change anything about the way Synaptics choose to distribute (or not) their firmwares. The Licence issue is still ongoing - they have provided some words, but they make it sound as if people are not free to redistribute the firmware, which they are. It's almost as if lawyers get paid by the hour. |
The shipping firmware for the SYN43436P does not support 4-way handshake offloading. This new firmware (version string "Version: 9.88.4.77 CRC: 143f9f15 Date: Thu 2022-03-31 17:25:16 CST Ucode Ver: 1043.20743 FWID: 01-3b307371") fixes that. See: #23
|
There's an official release from Synaptics available here: https://github.com/RPi-Distro/firmware-nonfree/blob/fdaf74c780ca7a29b12d62e5b0d37c38c2321e20/debian/config/brcm80211/brcm/brcmfmac43436-sdio.bin |
The shipping firmware for the SYN43436P does not support 4-way handshake offloading. This new firmware (version string "Version: 9.88.4.77 CRC: 143f9f15 Date: Thu 2022-03-31 17:25:16 CST Ucode Ver: 1043.20743 FWID: 01-3b307371") fixes that. See: #23
|
hmm i have a pi zero 2 and the wifi reconnect is broken since my last update. Can it be related? As soon as it looses contect to my mesh its gone and it was working fine before |
|
for methe new / current FW looses connection and keeps crashing:
P.S. its a Pi Zero 2, no 3a, the name is wrong |
|
debug log
|
|
Do you have In order to report this mesh-related problem to Synaptics I'm going to need more details of the configuration - please open a new issue with as much information as you can. |
|
yeah well i tried both, over_voltage 2 and 4, from my PI Zero Gen 1 i know its needed to get it stable streaming all day long. Now the Version 2 ran stable all winter long (same condtion, switching access in the mesh on a moving device) but i did a rpi-update like a week go and suddenly it became instable. First it looked like a mesh / wifi issue for now, but it similar to the instability i had with the Gen 1 pi Zero. A headless device is simply gone when it looses connection. For me it seems a bit related to FW right now. I mean thats whats get updated by rpi-update. And i even have the same with multiple mirco sds and OS setups for the same pi. currently my workaround is to reboot the devide when the AP is not pingable. But thats no real solution, obviously. |
|
Maybe the problem is caused by a bus issue. A script which is automatically rebooting the device keeps it accessible. Form syslog and messages it seems a bit like the bus get stuck or down at some point and that seem to lead to a wifi fw crash. The system itself stays on. I think it's not really related to the wifi infrastructure as no other device (and I have a lot) has issues. |
|
It does seem unlikely that something is transmitting bad packets - a firmware or hardware issue on the Zero 2 W is much more probable. You could try reverting to the previous version of the firmware: https://github.com/RPi-Distro/firmware-nonfree/blob/d95f6614b19cb2d3ead4f2e2ea4ba0a7397ac5c0/debian/config/brcm80211/brcm/brcmfmac43436f-sdio.bin That file needs to end up as |
|
found no file with "f" so i did this: after boot
Need some time to say if its better now. At least from the first minute it seems to stay online. Reconnects like this should be normal als its a mower driving though my garden ans switching APs in the Mesh |
Yes, that's the version I was referring to. If that ends up improving things it suggests a regression in the firmware, which bring me back to my request for a new issue with more details, i.e. what you did to a standard image, what you are running, e.t.c., so it can be reported to Synaptics. |
|
actually it seems to be normal = stable now, like it had been working for me with stock bullseye on my pi zero 2. When i did the rpi-update i get the problematic latest version which seems to be stable if I stay on one AP but it seem to loose connection especially switching between the mesh APs. And then only a reboot seem to solve it. Will create a issue for that, thus im not completely able to say what might go wrong but i can provide logs and all. |
|
i just ran update again and had the same issue again a few days. Now ill try a rpi update. cp brcmfmac43436f-sdio.bin /lib/firmware/brcm/brcmfmac43436-sdio.bin reboot |
|
|
Can you post the output of |
|
sorry for the delay. Grabed my mower again for season start and did a full update ink rpi update on the Pi Zero 2. The problem still exists. Wifi working fine for a few minutes and then suddenly gone and keeps down. Log on fault:
what I did now was:
|
|
I would like to say a huge thank you to the person created this issue. It may seem unrelated, but I have a set-top box based on S805X SoC with AP6236A WiFi chip. It's detected by Linux as BCM43430/2 and I tried to download the firmware for BCM43430 but it does not work. Until I found this issue and realized that BCM43430/2 needs BCM43436's firmware and now it worked. Still don't understand why they need BCM43436's firmware for BCM43430/2 and I hate their naming system! Edit: took me 4 months to find out this. |
BCM43430/2 can be thought of as "variant 2 of the BCM43430" family, which is called BCM43436 (or perhaps SYN43436) by Synaptics. I'm not a fan, either. |
|
Btw now the firmware loaded without error, and wlan0 is shown up in |
|
Okay I found the solution. Just use latest bcm43430b0 firmware from armbian and you will get it working. Again I hate their naming system. |
It seems like there are (at least) two different Raspberry Pi Zero 2 W revisions on the market, and they differ in terms of which WiFi chip is used.
The BCM43430/1 works as expected, and seems to match the chip used on the Raspberry Pi 3 B.
The BCM43430/2 however requires different firmware files (brcmfmac43436). This firmware unfortunately lacks support for 4-way handshake offloading, as can be verified by running
iw phy, which prints:…whereas on the BCM43430/1, Raspberry Pi 3B, 3B+ or 4B, it prints:
The 4-way handshake offloading is not just a performance optimization, but rather the feature that made using encrypted WiFi possible at all on platforms like https://gokrazy.org/ (not based on Raspberry Pi OS, entirely implemented in Go aside from the Linux kernel). With the offloading, connecting to WiFi is as simple as one Linux nl80211 API call, whereas without the offloading, a lot of work is required in userspace (
wpa_supplicant).Is the lack of 4-way handshake offloading an oversight in the current firmware blobs for the BCM43430/2?
Is there any chance we could get a fixed firmware version?
Thanks in advance
(PS: we figured this out in gokrazy/gokrazy#96, but I’m filing a separate issue as the history is getting lengthy…)
The text was updated successfully, but these errors were encountered: