zero w vs zero 2w

Then, like others said, I think the next step is to try a brand new SD card image of the latest RaspiOS download. I would be very surprised if that didn't work, or in other words: that would probably mean hardware error. (Or a very peculiar wifi access point, maybe.)

If the new card does work, I would still be surprised, namely that the update from the Z1W didn't work. If that is the case for everyone, I bet there will be lots of discussion about it over at

Exactly what the log entry(s) showed is always better than 'something like', but OK.

So, can other PCs, etc. connect to your wifi endpoint?

Anybody: on a wired network, I'd normally:

- scan the non-connecting device with nmap to see what ports are open

- install and start Wireshark on the non-responsive device to monitor incoming and outgoing traffic.

Do nmap and wireshark work for wifi connections? If not, what are their wifi equivalents?

I have a Pi Zero W but haven't yet powered it up: its intended to be used as part of the model aircraft timer project I've mentioned elsewhere.

yes

generally not in promiscuous mode, so only useful for capturing traffic to/from the local wifi interface.

One way is to wireshark over ethernet from a switch that can mirror the traffic from the wifi access point's port?

MAC addresses are unique to every single adapter in the world - so thata a red herring

"The Zero W uses the same chip and implementation as the Pi3, which is BCM43438 combo chip"

Whilst it is not clear what has been changed, the 2W has made changes to the wifi.

I am merely suggesting that the old kernel may need a rebuild to incorporate updated drivers.

The SD card was freshly installed from the 2021-05-07 image, which was newest available a few days ago and still is: Raspberry Pi OS Lite Release date: May 7th 2021 Kernel version: 5.10 Size: 444MB Then I did a "apt update ; apt dist-upgrade" cycle.

I, like you, think the only reason remaining is a hardware error. How can one decide whether it's a hardware error?

I'm going to have a look at the forums.

Bye, Stefan

Almost definitely, yes. But I'm quite sure that no normal user ever needs to do a kernel rebuild to get wifi working on their Pi. That should be fixed by regular apt updates.

"Should" doing a lot of work there, obvs.

Oh, indeed. Its all done automatically. Because the automatic build process detects the hardware and incorporates what it needs to.

But if something else does not force a kernel rebuild, moving to different hardware may not work.

Yes, they can. No problems there. Even a zero W can with the same SD card.

Bye, Stefan

Finally I found a solution for that issue.

pi@raspberrypi:~ $ sudo rfkill list

0: phy0: Wireless LAN Soft blocked: yes Hard blocked: no 1: hci0: Bluetooth Soft blocked: no Hard blocked: no pi@raspberrypi:~ $ sudo rfkill unblock wifi pi@raspberrypi:~ $ sudo rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no 1: hci0: Bluetooth Soft blocked: no Hard blocked: no pi@raspberrypi:~ $

The hint to the solution was hidden (at least for me) in /var/log/syslog

Nov 7 10:17:06 raspberrypi wpa_supplicant[406]: Successfully initialized wpa_supplicant Nov 7 10:17:06 raspberrypi systemd[1]: Started Login Service. Nov 7 10:17:06 raspberrypi systemd[1]: Started Avahi mDNS/DNS-SD Stack. Nov 7 10:17:06 raspberrypi systemd[1]: Started WPA supplicant. Nov 7 10:17:07 raspberrypi dhcpcd[381]: wlan0: connected to Access Point `' Nov 7 10:17:07 raspberrypi dhcpcd[381]: dhcpcd_prestartinterface: wlan0: Operation not possible due to RF-kill Nov 7 10:17:07 raspberrypi dhcpcd[381]: dhcpcd_prestartinterface: wlan0: Operation not possible due to RF-kill Nov 7 10:17:07 raspberrypi dhcpcd[381]: wlan0: waiting for carrier

I don't have a clue why this issue appeared only on the zero 2W and not on the zero W. Does anybody have an explanation or a pointer to a reason. For the moment I'm happy that it works now.

Thanks to everybody who tried to help me, Stefan

country code set?

No. Never did it on any of my machines. Why is it necessary?

On Sun, 7 Nov 2021 18:01:46 +0100, Stefan Kaintoch snipped-for-privacy@ratri.rincewind.kaintoch.de> declaimed the following:

Country code sets WiFi channel allocations -- some countries use a different set of channels from others.

so it knows what powers/frequencies to allow various radios to use.

Was your rf "unkill" a one-shot deal, or needed after each boot?

It could be required to make sure you never radiate RF on channels that are illegal in your country and/or at higher power than is allowed in your country.

For instance in the US 2.4GHz WiFi channels 12, 13 & 14 are not allowed.

Always struck me as being a bit daft having disallowed channels. I think the crims might look to see if there was something 'interesting' there.

Do you mean country-code in wpa-supplicant.conf? Yes, that was set. Particularly in DE it must be set. Otherwise radio will send with to much energy, and will not support channel 13.

I understood the LC_* settings. They are not relevant for WiFi.

one-shot.

Well no. 2.4 GHz is pretty much 'public space' and only a few countries restrict its usage in terms of the edge bands. All are restricted in terms of spectral power density though.

USA reserved a bit of te band for something else.

which is a TLDR for me.

Wikipdia summarises it as 'Weather radar an Military'.

Presumably weather radar was there before the 2.4 GHz band WiFi was allocated to WiFi since IIRC you need high RF frequencies to 'see' small raindrops. Presumably 'prior occupancy' also applies to the military.

most people have weather radars up a bit higher - 3-6Ghz Could well be battlefield radio comms tho.