Raspberry Pi Zero 2 W WiFi Not Working

[CNK]

I have WiFi working in PiCore 13.1.0 with the Raspberry Pi Zero W, but I can't get it to work with the Pi Zero 2 W. I'm connecting to unencrypted 802.11b/g wifi from my router.

From the top of onboot.lst I have:

Code: [Select]

firmware-rpi-wifi.tcz
wireless-KERNEL.tcz
wireless_tools.tcz

With the Zero W, WiFi works with these commands:

Code: [Select]

iwconfig wlan0 essid [my wifi network name]
udhcpc -i wlan0

On the Pi Zero 2 W udhcpc fails to obtain an IP address (keeps trying endlessly). Manually configuring a fixed IP just results in "network is unreachable" errors. It seems that the driver just isn't working, even though there's a wlan0 device and if I load wifi.tcz and run "sudo wifi.sh" it finds the name of my WiFi network, but also fails to connect to it.

"tce-status -i" confirms that all the extensions are loaded, including wireless-5.10.77-piCore-v7.tcz. Based on this thread, it seems like that should be enough.

I've done a lot of tests:

• Wrote the stock PiCore 13.1.0 image to a different Micro SD card, added the extensions for wifi (firmware-rpi-wifi.tcz, wireless-5.10.77-piCore-v7.tcz, and wireless_tools.tcz), and modified onboot.lst to include them. No other changes. Same problem.
• Checked the MD5sums of firmware-rpi-wifi.tcz, wireless-5.10.77-piCore-v7.tcz, and wireless_tools.tcz, and they all match the .md5.txt files.
• Tried booting RPi OS and WiFi worked there, so not a hardware fault.
• Tried rfkill from util-linux.tcz, but it reports that the wlan0 interface is unblocked.
• Loaded the sha256_generic module from 5.10.77-piCore-v7_modules.tar.xz, which prevents the error in dmesg about the "X.509 certificate", before loading any of the wifi extensions, but it didn't affect this problem.
• I think I got PiCore to also say "cfg80211: loaded regulatory.db is malformed or signature is missing/invalid" (like RPi OS) instead of "cfg80211: failed to load regulatory.db" in dmesg at one point as well, by loading extra extensions, but it didn't help. This error is also there with the Pi Zero W anyway.

Hardware stats:

Code: [Select]

Hardware        : BCM2835
Revision        : 902120
Serial          : 0000000091c31ace
Model           : Raspberry Pi Zero 2 W Rev 1.0

Attached is a comparison of relevent bits from dmesg for PiCore on the Pi Zero 2 W and Pi Zero W, plus RPi OS on the Pi Zero 2 W where WiFi works (got a forum error when I tried to include it in my post).

I don't know what the problem could be. Is my Pi Zero 2 W different to others? RPi OS claims to be using the same "brcmfmac" driver, and has similar logs in dmesg, so I'm confused. Is there some trick that I'm missing here?

[Paul_123]

How new is your pi 0 2w?

WiFi chips on this board is a mess.  There are different chips with different capabilities.  It seem raspiOS is using different firmware.  I’ll take a look and see if I can get an updated package.

[Paul_123]

Taking a closer look.  regulatory.db is contained in extension regdb.tcz   This should be a dependency of the kernel wireless drivers, but I see that dep is missing.  I'll fix that in a bit.  make sure to load it with all of your other firmware.

I have also updated the firmware for the brcm43436,  It used to be a symlink to a different firmware.   The funny thing is that I cannot find a record of the version string that is showing in your RaspiOS example.........and I copied the firmware from the raspios deb installer.......   As I said, it is a real mess.

[CNK]

My Pi Zero 2 W was ordered on Jan 31st 2022 (it took me quite a while to get around to trying to switch over from the Zero W - seems my fears weren't misplaced). I don't know if they're region-specific, but I ordered from a supplier here in Australia and the chip has "AU" printed on it.

I added the new .dep file for wireless-5.10.77-piCore-v7.tcz and regdb.tcz (which I had tried before, as it turns out). I downloaded the updated firmware-rpi-wifi.tcz (md5sum: 95391eb17acde417de98204bb6e70a03). With the sha256_generic module manually loaded before the extensions, I got the cleanest-looking dmesg log yet:

Code: [Select]

[  147.537025] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[  147.574316] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[  147.603072] brcmfmac: F1 signature read @0x18000000=0x1542a9a6
[  147.609349] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43436-sdio for chip BCM43430/2
[  147.610581] usbcore: registered new interface driver brcmfmac
[  147.767443] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43436-sdio for chip BCM43430/2
[  147.767540] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43436-sdio for chip BCM43430/2
[  147.783914] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/2 wl0: Mar 31 2022 17:24:51 version 9.88.4.77 (g58bc5cc) FWID 01-3b307371
[  209.960130] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

But I still have the same problem - a wireless interface that won't connect to anything.

I take it that wireless-5.10.77-piCore-v7.tcz hasn't been changed because the md5sum is the same as the one I already had.

[Paul_123]

So post what you are trying and your configurations and errors messages or WiFi diagnostics.

[CNK]

So post what you are trying and your configurations and errors messages or WiFi diagnostics.

For the last test:

• Rename onboot.lst to onboot.lst.disabled
• Boot on Pi Zero 2 W
• Copy sha256_generic.ko module to /lib/modules/(kernel name)/kernel/crypto/
• sudo insmod /lib/modules/(kernel name)/kernel/crypto/sha256_generic.ko (possibly I don't need the previous step)
• tce-load -i firmware-rpi-wifi.tcz wireless-KERNEL.tcz wireless_tools.tcz (all load OK, including regdb.tcz)
• sudo iwconfig wlan0 essid (my wifi network name)
• sudo udhcpc -i wlan0
• Watch it endlessly print lines of "udhcpc: sending discover" for a while
• Interrupt udhcpc, and check that the ESSID is correct in "iwconfig wlan0"

More details on bits of that are in the first post.

[Paul_123]

Have you brought the interface up?

[CNK]

Have you brought the interface up?

In my experience udhcpc always does that itself. Still, I just tried "sudo ifconfig wlan0 up" before "sudo udhcpc -i wlan0" and got the same result ("udhcpc: sending discover" forever).

Same with "sudo ifconfig wlan0 down", then"sudo ifconfig wlan0 up",  before "sudo udhcpc -i wlan0". Also I certainly brought it up manually when I tried the fixed IP configuration.

This is printed to dmesg every time wlan0 is brought up (which I think is normal):

Code: [Select]

brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled


[Paul_123]

It's likely the open network that is causing the problem, not using wpa_supplicant.   The wifi firmware does require country code to be set for some channels to work.

I would use wpa_supplicant.conf to configure the interface, that way country code can be set properly.....just set it up for no encryption.

[CNK]

Ah ha! Yes after creating a /etc/wpa_supplicant.conf file, loading wpa_supplicant.tcz, and running:

Code: [Select]

sudo wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf &

Now "sudo udhcpc -i wlan0" finally works and I can use the WiFi.

For reference, the wpa_supplicant.conf that I ended up with for my unencrypted network is:

Code: [Select]

country=AU
update_config=1

network={
    ssid="(my wifi network name)"
    key_mgmt=NONE
}

Thanks for the help. wpa_supplicant is new to me so it didn't come to mind. It seems now that you can't even escape the complications of wireless encryption systems by not using them!

[patrikg]

May I ask you why using not encrypted wifi network ?

[CNK]

May I ask you why using not encrypted wifi network ?

Well there's no point. It's my home WiFi and I live in a rural area far enough away from any land where other people go (unless they're visiting me, and that's rare enough as well) that I'm the only one close enough to get signal from my wireless router.

Keeping things unencrypted makes things much easier. Especially as I use old computers on a regular basis.

[patrikg]

Thanks for the answer.

You may also gain more throughput out of the wifi, not need to encrypt or decrypt the data.

[CentralWare]

How new is your pi 0 2w?
WiFi chips on this board is a mess.  There are different chips with different capabilities.  It seem raspiOS is using different firmware.  I’ll take a look and see if I can get an updated package.

@Paul_123: Do we have a list of chips (and associated drivers), by chance, since its release?  (This would be a good post to wiki'fy if/when obtaining RasPi boards becomes more fluid.)  I ordered one about six ten months ago; still have yet to plug it in as time is a scarce luxury, but it's nice to know how "messy" things are for this young board!

[Paul_123]

Nope, I don’t even know if the rpi guys know the production date of the changes.   The driver is the same, it’s that they keep tweaking the firmware. And synaptic routinely fixes one issue and then creates a new one.

The chip versions, other than keeping drivers/firmware updated, It’s mostly in the Bluetooth capabilities, and the capabilities in AP mode.