• zero w vs zero 2w

    From Stefan Kaintoch@3:770/3 to All on Sat Nov 6 10:29:58 2021
    Hi *.*,

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    BTW: it is not an issue with the DHCP server. The 2W doesn't even send
    DHCP requests.

    TIA, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Stefan Kaintoch on Sat Nov 6 10:56:15 2021
    On 06/11/2021 09:29, Stefan Kaintoch wrote:
    Hi *.*,

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    BTW: it is not an issue with the DHCP server. The 2W doesn't even send
    DHCP requests.

    TIA, Stefan

    Sounds unlikely, but MAC address different?

    --
    Cheers,
    David
    Web: http://www.satsignal.eu
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Stefan Kaintoch on Sat Nov 6 11:08:55 2021
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Hi *.*,

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    Have you updated the firmware? I think there have been some pin-related changes for the 2W, which may affect the way the wifi is connected. If
    you're using an old SD card image that may be the problem.

    sudo rpi-update

    should handle that.

    Theo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Stefan Kaintoch on Sat Nov 6 12:15:11 2021
    On 06-11-2021 10:29, Stefan Kaintoch wrote:
    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    BTW: it is not an issue with the DHCP server. The 2W doesn't even send
    DHCP requests.


    The Z2W has a slightly different wifi chip, so you need an absolutely up-to-date RaspiOS 32-bit. (Not sure if the driver is in the 64-bit
    version yet; that's still in beta.) Both these commands are essential,
    in this order:

    sudo apt update
    sudo apt -y full-upgrade

    then shut down and pop the card into the Z2W.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to David Taylor on Sat Nov 6 12:29:50 2021
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 06/11/2021 09:29, Stefan Kaintoch wrote:
    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    BTW: it is not an issue with the DHCP server. The 2W doesn't even send
    DHCP requests.

    TIA, Stefan

    Sounds unlikely, but MAC address different?

    MAC addresses should be different. Two different WLAN chips. But as I
    wrote: there are no DHCP requests from W2.

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Stefan Kaintoch on Sat Nov 6 11:35:55 2021
    Stefan Kaintoch wrote:

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    does raspbian bind the WLAN interface to the physical MAC address?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Theo on Sat Nov 6 15:03:16 2021
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Have you updated the firmware? I think there have been some pin-related changes for the 2W, which may affect the way the wifi is connected. If you're using an old SD card image that may be the problem.

    sudo rpi-update

    The OS has been updated before testing the Z2W using "sudo apt update ;
    sudo apt dist-upgrade". I think that should also update the firmware.
    But if not: How can I rpi-update without network? rpi-update complains
    about missing network.

    TIA, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Stefan Kaintoch on Sat Nov 6 13:41:14 2021
    On 06/11/2021 11:29, Stefan Kaintoch wrote:
    MAC addresses should be different. Two different WLAN chips. But as I
    wrote: there are no DHCP requests from W2.

    Bye, Stefan

    Yes, of course, that's why I thought it unlikely. If it were me, I would try a completely fresh card with a minimal standard Raspberry Pi OS. I think the wireless /has/ changed, but I would be amazed if the Wi-Fi were non functional.
    You might also try reconfiguring the Wi-Fi from the desktop (on a slightly bigger OS).

    Be sure your OS and firmware are up-to-date, as others have suggested.

    --
    Cheers,
    David
    Web: http://www.satsignal.eu
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Andy Burns on Sat Nov 6 14:43:54 2021
    Andy Burns <usenet@andyburns.uk> wrote:
    Stefan Kaintoch wrote:

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    Has anybody an idea what's the difference? Or how can I investigate why
    one has a WLAN connection, and the other has not.

    does raspbian bind the WLAN interface to the physical MAC address?

    I think so, but am not sure, as I'm not sure what your question exactly
    means.
    "ip addr" shows the interface wlan0 with a MAC. But the interface is
    down.

    In syslog there's a message which says that wlan0 can't get a carrier.
    I think that's the root cause. But why can't it get a carrier?

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to A. Dumas on Sat Nov 6 14:45:29 2021
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    On 06-11-2021 10:29, Stefan Kaintoch wrote:
    The Z2W has a slightly different wifi chip, so you need an absolutely up-to-date RaspiOS 32-bit. (Not sure if the driver is in the 64-bit
    version yet; that's still in beta.) Both these commands are essential,
    in this order:

    sudo apt update
    sudo apt -y full-upgrade

    then shut down and pop the card into the Z2W.

    I did this before inserting the card the first time into the Z2W.

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to All on Sat Nov 6 16:19:52 2021
    Den 2021-11-06 kl. 15:25, skrev Andy Burns:
    Stefan Kaintoch wrote:

    Andy Burns wrote:

    does raspbian bind the WLAN interface to the physical MAC address?

    I think so, but am not sure, as I'm not sure what your question exactly
    means.

    some distros (not really talking about PIs) when they first see e.g.
    eth0 will check the MAC addr, and then store that association, if you
    remove the disk/SD and boot a different computer, they'll see a
    different MAC addr and may associate it with e.g. eth1, as a different NIC.

    "ip addr" shows the interface wlan0 with a MAC. But the interface is
    down.

    sounds like MAC address isn't your issue then.



    You said you switch the card between 2 zeros. Which MAC is it dispalying?

    1 or 2?
    Does the MAC change when you switch pi?
    Or is somethinge cached?



    --
    Björn
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Stefan Kaintoch on Sat Nov 6 14:25:22 2021
    Stefan Kaintoch wrote:

    Andy Burns wrote:

    does raspbian bind the WLAN interface to the physical MAC address?

    I think so, but am not sure, as I'm not sure what your question exactly means.

    some distros (not really talking about PIs) when they first see e.g. eth0 will check the MAC addr, and then store that association, if you remove the disk/SD and boot a different computer, they'll see a different MAC addr and may associate it with e.g. eth1, as a different NIC.

    "ip addr" shows the interface wlan0 with a MAC. But the interface is
    down.

    sounds like MAC address isn't your issue then.

    In syslog there's a message which says that wlan0 can't get a carrier.
    I think that's the root cause. But why can't it get a carrier?

    I'd test a brand new install of latest o/s to make sure the WLAN hardware is working.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to A. Dumas on Sat Nov 6 15:46:06 2021
    On 06/11/2021 15:23, A. Dumas wrote:
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Have you updated the firmware? I think there have been some pin-related
    changes for the 2W, which may affect the way the wifi is connected. If
    you're using an old SD card image that may be the problem.

    sudo rpi-update

    should handle that.

    Surely the firmware needed for an officially released board is in the
    general release software?

    It may well be, but unless you do an image build, it may well not be incorporated into the current kernel.

    At one point a kernel upgrade destroyed my wifi - the broadcomm driver
    for that kernel release were not supplied with it.

    My guess is you have to force a kernel rebuild. https://www.systutorials.com/docs/linux/man/8-update-initramfs/

    is probably the tool to use.



    --
    "Strange as it seems, no amount of learning can cure stupidity, and
    higher education positively fortifies it."

    - Stephen Vizinczey
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Theo on Sat Nov 6 15:23:20 2021
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Have you updated the firmware? I think there have been some pin-related changes for the 2W, which may affect the way the wifi is connected. If you're using an old SD card image that may be the problem.

    sudo rpi-update

    should handle that.

    Surely the firmware needed for an officially released board is in the
    general release software? In the very early days of Raspberry Pi you needed rpi-update for any firmware update but now the standard "apt upgrade" also delivers new firmware and the official advice has shifted to: never ever
    use rpi-update unless you know exactly what issue you're having, how
    rpi-update attempts to solve it, and that it may well break your install.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to David Taylor on Sat Nov 6 16:16:37 2021
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 06/11/2021 11:29, Stefan Kaintoch wrote:
    MAC addresses should be different. Two different WLAN chips. But as I
    wrote: there are no DHCP requests from W2.

    Bye, Stefan

    Yes, of course, that's why I thought it unlikely. If it were me, I would try a
    completely fresh card with a minimal standard Raspberry Pi OS. I think the wireless /has/ changed, but I would be amazed if the Wi-Fi were non functional.
    You might also try reconfiguring the Wi-Fi from the desktop (on a slightly bigger OS).

    Be sure your OS and firmware are up-to-date, as others have suggested.

    The SD was freshly installed (RaspOS from 2021-05-xx), then "apt update;
    apt dist-upgrade".
    I tried a rpi-update on the Pi zero W. That brought 2 new files in
    /boot: bcm2710-rpi-zero-2[-w].dtb.

    Unfortunately that didn't make the trick. WLAN still not working.

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to The Natural Philosopher on Sat Nov 6 15:58:28 2021
    On 06/11/2021 15:46, The Natural Philosopher wrote:
    On 06/11/2021 15:23, A. Dumas wrote:
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Have you updated the firmware?  I think there have been some pin-related >>> changes for the 2W, which may affect the way the wifi is connected.  If >>> you're using an old SD card image that may be the problem.

    sudo rpi-update

    should handle that.

    Surely the firmware needed for an officially released board is in the
    general release software?

    It may well be, but unless you do an image build, it may well not be incorporated into the current kernel.

    At one point a kernel upgrade destroyed my wifi - the broadcomm driver
    for that kernel release were not supplied with it.

    My guess is you have to force a kernel rebuild. https://www.systutorials.com/docs/linux/man/8-update-initramfs/

     is probably the tool to use.



    seems like 'dracut -f' is what you need to run on the new system ...

    --
    For in reason, all government without the consent of the governed is the
    very definition of slavery.

    Jonathan Swift
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Stefan Kaintoch on Sat Nov 6 16:44:28 2021
    On 06/11/2021 15:16, Stefan Kaintoch wrote:
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 06/11/2021 11:29, Stefan Kaintoch wrote:
    MAC addresses should be different. Two different WLAN chips. But as I
    wrote: there are no DHCP requests from W2.

    Bye, Stefan

    Yes, of course, that's why I thought it unlikely. If it were me, I would try a
    completely fresh card with a minimal standard Raspberry Pi OS. I think the >> wireless /has/ changed, but I would be amazed if the Wi-Fi were non functional.
    You might also try reconfiguring the Wi-Fi from the desktop (on a slightly
    bigger OS).

    Be sure your OS and firmware are up-to-date, as others have suggested.

    The SD was freshly installed (RaspOS from 2021-05-xx), then "apt update;
    apt dist-upgrade".
    I tried a rpi-update on the Pi zero W. That brought 2 new files in
    /boot: bcm2710-rpi-zero-2[-w].dtb.

    try an apt upgrade now...


    Unfortunately that didn't make the trick. WLAN still not working.

    Bye, Stefan

    You probly need to force a kernel rebuild and new initramfs and install it.

    Might be easy to downgrade kernel and upgrade it.

    --
    No Apple devices were knowingly used in the preparation of this post.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Andy Burns on Sat Nov 6 17:24:43 2021
    Andy Burns <usenet@andyburns.uk> wrote:
    Stefan Kaintoch wrote:

    Andy Burns wrote:

    does raspbian bind the WLAN interface to the physical MAC address?

    I think so, but am not sure, as I'm not sure what your question exactly means.

    some distros (not really talking about PIs) when they first see e.g. eth0 will
    check the MAC addr, and then store that association, if you remove the disk/SD
    and boot a different computer, they'll see a different MAC addr and may associate it with e.g. eth1, as a different NIC.

    The fix for the 'remembering' of network interfaces is usually to delete a
    file
    /etc/udev/rules.d/70-persistent-net.rules
    There's no harm in deleting it to see if it fixes the problem.

    (this is particularly fun when your password is stored on the network so you need an active network to login, but you need to delete the file to make the network work)

    Theo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to The Natural Philosopher on Sat Nov 6 18:21:53 2021
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 06/11/2021 15:16, Stefan Kaintoch wrote:
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 06/11/2021 11:29, Stefan Kaintoch wrote:
    MAC addresses should be different. Two different WLAN chips. But as I
    wrote: there are no DHCP requests from W2.

    Bye, Stefan

    Yes, of course, that's why I thought it unlikely. If it were me, I would try a
    completely fresh card with a minimal standard Raspberry Pi OS. I think the >>> wireless /has/ changed, but I would be amazed if the Wi-Fi were non functional.
    You might also try reconfiguring the Wi-Fi from the desktop (on a slightly
    bigger OS).

    Be sure your OS and firmware are up-to-date, as others have suggested.

    The SD was freshly installed (RaspOS from 2021-05-xx), then "apt update;
    apt dist-upgrade".
    I tried a rpi-update on the Pi zero W. That brought 2 new files in
    /boot: bcm2710-rpi-zero-2[-w].dtb.

    try an apt upgrade now...

    Already done several times; no changes.

    You probly need to force a kernel rebuild and new initramfs and install it.

    Why?

    Loaded modules are cfg80211, brcmfmac and brcmutil.
    MAC addresses between zero W and zero 2 W differ.

    TIA, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Stefan Kaintoch on Sat Nov 6 18:50:54 2021
    On Sat, 6 Nov 2021 18:21:53 +0100, Stefan Kaintoch wrote:

    Loaded modules are cfg80211, brcmfmac and brcmutil. MAC addresses
    between zero W and zero 2 W differ.

    I may have missed seeing you mention it, but have you looked in the
    system logs to see what, if anything, they show about initialising wifi?


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Stefan Kaintoch on Sun Nov 7 10:38:03 2021
    On 06-11-2021 14:45, Stefan Kaintoch wrote:
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    sudo apt update
    sudo apt -y full-upgrade
    then shut down and pop the card into the Z2W.

    I did this before inserting the card the first time into the Z2W.


    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 https://forums.raspberrypi.com
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Martin Gregorie on Sun Nov 7 10:25:20 2021
    Martin Gregorie <martin@mydomain.invalid> wrote:
    On Sat, 6 Nov 2021 18:21:53 +0100, Stefan Kaintoch wrote:

    Loaded modules are cfg80211, brcmfmac and brcmutil. MAC addresses
    between zero W and zero 2 W differ.

    I may have missed seeing you mention it, but have you looked in the
    system logs to see what, if anything, they show about initialising wifi?

    Yes, I did. Something like "carrier not found".
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Stefan Kaintoch on Sun Nov 7 11:55:55 2021
    On Sun, 7 Nov 2021 10:25:20 +0100, Stefan Kaintoch wrote:

    Martin Gregorie <martin@mydomain.invalid> wrote:
    On Sat, 6 Nov 2021 18:21:53 +0100, Stefan Kaintoch wrote:

    Loaded modules are cfg80211, brcmfmac and brcmutil. MAC addresses
    between zero W and zero 2 W differ.

    I may have missed seeing you mention it, but have you looked in the
    system logs to see what, if anything, they show about initialising
    wifi?

    Yes, I did. Something like "carrier not found".

    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.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Stefan Kaintoch on Sun Nov 7 12:09:04 2021
    On 06/11/2021 17:21, Stefan Kaintoch wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 06/11/2021 15:16, Stefan Kaintoch wrote:
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 06/11/2021 11:29, Stefan Kaintoch wrote:
    MAC addresses should be different. Two different WLAN chips. But as I >>>>> wrote: there are no DHCP requests from W2.

    Bye, Stefan

    Yes, of course, that's why I thought it unlikely. If it were me, I would try a
    completely fresh card with a minimal standard Raspberry Pi OS. I think the
    wireless /has/ changed, but I would be amazed if the Wi-Fi were non functional.
    You might also try reconfiguring the Wi-Fi from the desktop (on a slightly
    bigger OS).

    Be sure your OS and firmware are up-to-date, as others have suggested.

    The SD was freshly installed (RaspOS from 2021-05-xx), then "apt update; >>> apt dist-upgrade".
    I tried a rpi-update on the Pi zero W. That brought 2 new files in
    /boot: bcm2710-rpi-zero-2[-w].dtb.

    try an apt upgrade now...

    Already done several times; no changes.

    You probly need to force a kernel rebuild and new initramfs and install it.

    Why?

    Loaded modules are cfg80211, brcmfmac and brcmutil.
    MAC addresses between zero W and zero 2 W differ.
    h
    MAC addresses are unique to every single adapter in the world - so
    thata a red herring


    TIA, Stefan

    "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.

    --
    Labour - a bunch of rich people convincing poor people to vote for rich
    people by telling poor people that "other" rich people are the reason
    they are poor.

    Peter Thompson
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Martin Gregorie on Sun Nov 7 12:06:55 2021
    Martin Gregorie wrote:

    Do nmap

    yes

    and wireshark work for wifi connections?

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

    If not, what are their wifi equivalents?

    One way is to wireshark over ethernet from a switch that can mirror the traffic from the wifi access point's port?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to A. Dumas on Sun Nov 7 12:56:44 2021
    On 07/11/2021 12:28, A. Dumas wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    I am merely suggesting that the old kernel may need a rebuild to
    incorporate updated drivers.

    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.


    --
    “I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most
    obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which
    they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.”

    ― Leo Tolstoy
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to A. Dumas on Sun Nov 7 13:27:59 2021
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    On 06-11-2021 14:45, Stefan Kaintoch wrote:
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    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.)

    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?

    https://forums.raspberrypi.com

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

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to The Natural Philosopher on Sun Nov 7 12:28:15 2021
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    I am merely suggesting that the old kernel may need a rebuild to
    incorporate updated drivers.

    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Martin Gregorie on Sun Nov 7 14:09:00 2021
    Martin Gregorie <martin@mydomain.invalid> wrote:
    On Sun, 7 Nov 2021 10:25:20 +0100, Stefan Kaintoch wrote:

    Martin Gregorie <martin@mydomain.invalid> wrote:
    On Sat, 6 Nov 2021 18:21:53 +0100, Stefan Kaintoch wrote:

    Loaded modules are cfg80211, brcmfmac and brcmutil. MAC addresses
    between zero W and zero 2 W differ.

    I may have missed seeing you mention it, but have you looked in the
    system logs to see what, if anything, they show about initialising
    wifi?

    Yes, I did. Something like "carrier not found".

    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?

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

    Bye, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Stefan Kaintoch on Sun Nov 7 14:20:14 2021
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Hi *.*,

    There's a RPi zero w (1W) and a RPi zero 2w (2W).
    Both can boot from the same (not a clone, physically the identical)
    SD-card. But (there always is a but) the 1W has WLAN, the 2W doesn't
    have.

    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Stefan Kaintoch on Sun Nov 7 14:21:07 2021
    Stefan Kaintoch wrote:

    Finally I found a solution for that issue.
    pi@raspberrypi:~ $ sudo rfkill unblock wifi

    country code set?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sun Nov 7 12:11:22 2021
    On Sun, 7 Nov 2021 18:01:46 +0100, Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> declaimed the following:

    Andy Burns <usenet@andyburns.uk> wrote:
    Stefan Kaintoch wrote:

    Finally I found a solution for that issue.
    pi@raspberrypi:~ $ sudo rfkill unblock wifi

    country code set?

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

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


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Andy Burns on Sun Nov 7 18:01:46 2021
    Andy Burns <usenet@andyburns.uk> wrote:
    Stefan Kaintoch wrote:

    Finally I found a solution for that issue.
    pi@raspberrypi:~ $ sudo rfkill unblock wifi

    country code set?

    No. Never did it on any of my machines.
    Why is it necessary?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Stefan Kaintoch on Sun Nov 7 17:13:13 2021
    Stefan Kaintoch wrote:

    Andy Burns wrote:

    country code set?

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

    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?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Brian Gregory@3:770/3 to Stefan Kaintoch on Sun Nov 7 17:13:38 2021
    On 07/11/2021 17:01, Stefan Kaintoch wrote:
    No. Never did it on any of my machines.
    Why is it necessary?

    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.

    --
    Brian Gregory (in England).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Folderol@3:770/3 to Brian Gregory on Sun Nov 7 19:03:35 2021
    On Sun, 7 Nov 2021 17:13:38 +0000
    Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:

    On 07/11/2021 17:01, Stefan Kaintoch wrote:
    No. Never did it on any of my machines.
    Why is it necessary?

    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.

    --
    Basic
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Andy Burns on Mon Nov 8 06:23:42 2021
    Andy Burns <usenet@andyburns.uk> wrote:
    Stefan Kaintoch wrote:

    Andy Burns wrote:

    country code set?

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

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

    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.

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

    one-shot.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Folderol on Mon Nov 8 11:36:09 2021
    On 07/11/2021 19:03, Folderol wrote:
    On Sun, 7 Nov 2021 17:13:38 +0000
    Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:

    On 07/11/2021 17:01, Stefan Kaintoch wrote:
    No. Never did it on any of my machines.
    Why is it necessary?

    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.

    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.

    https://docs.fcc.gov/public/attachments/FCC-16-181A1.pdf

    which is a TLDR for me.


    --
    “I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most
    obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which
    they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.”

    ― Leo Tolstoy
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Mon Nov 8 12:42:00 2021
    On Mon, 8 Nov 2021 11:36:09 +0000, The Natural Philosopher wrote:

    USA reserved a bit of te band for something else.

    https://docs.fcc.gov/public/attachments/FCC-16-181A1.pdf

    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.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Martin Gregorie on Mon Nov 8 14:55:19 2021
    On 08/11/2021 12:42, Martin Gregorie wrote:
    On Mon, 8 Nov 2021 11:36:09 +0000, The Natural Philosopher wrote:

    USA reserved a bit of te band for something else.

    https://docs.fcc.gov/public/attachments/FCC-16-181A1.pdf

    which is a TLDR for me.

    Wikipdia summarises it as 'Weather radar an Military'.

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


    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.




    --
    Climate Change: Socialism wearing a lab coat.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)