[RPi5] Network Disappeared

    • New
    Quote from kszaq

    To me it looks like iwd is trying to offload SAE but the firmware only supports doing this with wpa_supplicant, iwd fails to authenticate and does not fallback to WPA2.

    Edit: These 2 threads seem to confirm that WPA3 does not work with iwd (yet):
    https://github.com/raspberrypi/linux/issues/4718
    https://github.com/raspberrypi/linux/issues/6130

    So basically, if our whole network has WPA3 settings on (my whole eero network does), until there is a fix we won't have any network settings correct?

    So this is the issue and nothing related to IPv6?

    • New
    Quote from chewitt

    popcornmix what's the latest on that front? - I can see pelwell and @6by9 commenting so it's presumably on their radar.

    Sorry I have no knowledge of this issue beyond this.

    I believe officially WPA3 is not supported on any Pi boards, although with combinations of custom versions of wifi firmware, kernel patches and userland libraries some users have had success, but I don't believe it's mature enough to say "this will work".

    • New

    No plans to revert official images to wpa_supplicant and the overall number of issues and impacted users is low. LE13 should be out sooner than later, and RPi devices should be using Linux 6.12 which we expect to be the next LTS release and thus the next base for RPi kernels too. It's not hard to self-build something that still uses wpa though; we intentionally left the package in the buildsystem so it was possible.

    • New
    Quote from Da Flex

    This is from the "working" log:

    Code
    Oct 08 17:44:20.146869 LibreELEC connmand[631]: Interface wlan0 [ wifi ] error "invalid-key"
Oct 08 17:44:20.146905 LibreELEC connmand[631]: Interface wlan0 [ wifi ] state is failure

    Seems like you always had a wrong WiFi configuration. Check your keys.


    I will check but.....what key are we talking exactly from?

    And why is the connection running without issues if there is something "wrong" with it?

    Quote from kszaq

    One more thing: 56c531c is the first non-working build? If it stopped working in 4b9746e, it would be much easier to blame the iwd update. :D

    Cant tell that for sure, as i usually only update once a week around friday, and the fist build i had that happen was either the one from the 10/25 or 10/29 (deleted it from my NAS, so that i not accidentally revert to an "unstable" build if needed)


    But if i understand correctly, the connection issue is mainly because of WPA3.

    Will check that too, but im quite sure that i never explicitly set the WPA standard which should be used (router should be set to WPA2/3 as network devices mostly are mixed here) so the kodi/libreelec install had choosen that by itself.

    • New
    Quote from Wolfpig

    I will check but.....what key are we talking exactly from?

    And why is the connection running without issues if there is something "wrong" with it?

    The WiFi key was wrong at the first attempt to connect, but at the second attempt it worked:

    Code
    Oct 08 17:44:37.351915 LibreELEC connmand[631]: Interface wlan0 [ wifi ] state is ready
Oct 08 17:44:37.352030 LibreELEC connmand[631]: Interface wlan0 [ wifi ] is the default

    This message only appears once, right before the second attempt:

    Code
    Oct 08 17:44:31.629219 LibreELEC iwd[1001]: hardware_rekey not supported
Oct 08 17:44:31.629788 LibreELEC iwd[1001]: event: state, old: connecting, new: connected

    So I think kszaq is right, and it's a bug at iwd.

    • New

    Not a bug as such, but simply they are not yet supported. Looking at the open tickets and the above seems to be getting to the bottom of the wireless issues reported, this is a good another “now known” item.

    The list probably looks like the below now: (noting that these are shortcomings in drivers, kernels, supplicants, ….) The “But it should work” philosophy whilst idealistic is not true even in commercial / non iwd / non LE landscapes. Wireless will probably always have its challenges given standards and compatibility across the many elements that make it up - but every known reproducible issue should improves our support and hopefully the Linux wireless ecosystem system.

    Known issues

    • wireless networks with FT enabled may not work
    • wireless networks with WPA3 may not work
    • wireless networks where the signal strength is low may not authenticate
    • The wl bcm_sta driver (at this stage) will be dropped from LE13 - (lack of patches to make it compatible with linux 6.12)

      For these 4 known issues - there does seem to be movement upstream in “fixing“ / “adding support for”
    • New
    Quote from Da Flex

    The WiFi key was wrong at the first attempt to connect, but at the second attempt it worked:

    Code
    Oct 08 17:44:37.351915 LibreELEC connmand[631]: Interface wlan0 [ wifi ] state is ready
Oct 08 17:44:37.352030 LibreELEC connmand[631]: Interface wlan0 [ wifi ] is the default

    This message only appears once, right before the second attempt:

    Code
    Oct 08 17:44:31.629219 LibreELEC iwd[1001]: hardware_rekey not supported
Oct 08 17:44:31.629788 LibreELEC iwd[1001]: event: state, old: connecting, new: connected

    So I think kszaq is right, and it's a bug at iwd.

    As i still have no idea what it is, and as i probably cant change that by myself.....


    BTW: As i looked today a bit further


    a) the working nightly is connecting correctly with WPA2 (not really a surprise if it does not support wpa3)

    b) the non working nightly only sets the Wireless state to ready, it does neither receive the internal ip from the router and does not see the router as the DNS source (the field there is kept blank, which probably also the reason why it sets the connection state or what it was to auto instead dhcp)

    c) manually setting the ip, dns etc. makes no difference


    As i have no real problems with the running nightly, i will keep that for a bit and see if that problem might get squished out in the near future.

    Would i need to report that as a possible bug somewhere?

    • New

    I think I will probably do the same. Just keep the current 20th build which I know still works, and wait to see if this gets fixed in the future.

    • New

    Can you guys check this older firmware that I mentioned earlier? It's quite easy to do but please make sure that you are able to connect to your RPi over ethernet in case this firmware does not work at all!

    First, run the nightly with working WiFi, connect over SSH and execute this:

    Code
    mkdir -p /storage/.config/firmware/cypress
wget https://github.com/RPi-Distro/firmware-nonfree/raw/ad23f33a29fb7f8bc344d80d0eb40abe1953d145/debian/config/brcm80211/cypress/cyfmac43455-sdio-standard.bin -O /storage/.config/firmware/cypress/cyfmac43455-sdio.bin

    Reboot. Check WiFi. If working, update to latest nightly and check WiFi. Please report your result.

    In case this firmware breaks WiFi even on older builds, delete it:

    Code
    rm /storage/.config/firmware/cypress/cyfmac43455-sdio.bin
    • New
    Quote from kszaq

    Can you guys check this older firmware that I mentioned earlier? It's quite easy to do but please make sure that you are able to connect to your RPi over ethernet in case this firmware does not work at all!

    First, run the nightly with working WiFi, connect over SSH and execute this:

    Code
    mkdir -p /storage/.config/firmware/cypress
wget https://github.com/RPi-Distro/firmware-nonfree/raw/ad23f33a29fb7f8bc344d80d0eb40abe1953d145/debian/config/brcm80211/cypress/cyfmac43455-sdio-standard.bin -O /storage/.config/firmware/cypress/cyfmac43455-sdio.bin

    Reboot. Check WiFi. If working, update to latest nightly and check WiFi. Please report your result.

    In case this firmware breaks WiFi even on older builds, delete it:

    Code
    rm /storage/.config/firmware/cypress/cyfmac43455-sdio.bin

    I haven't ever SSH'd into the Pi unfortunately. I do have Putty on the windows laptop, and tried logging in with the instructions here from the documentation...but no luck yet getting into the Pi to be able to test this. Maybe with some extra guidance I could make it happen.

    Open a terminal window on your computer and enter the following command, replacing the <ip address> placeholder with the IP address of the Raspberry Pi you’re trying to connect to and <username> with your username:

    Code
    $ ssh <username>@<ip address>

    When the connection works, you will see a security warning. Type yes to continue. You will only see this warning the first time you connect.

    Enter your account password when prompted.

    You should now see the Raspberry Pi command prompt:

    Code
    <username>@<hostname> ~ $

    You are now connected to the Raspberry Pi remotely, and can execute commands.

    • New

    In LibreELEC Settings enable SSH, don't disable password. Default password is 'libreelec'. You should be then able to connect with PuTTy by entering Pi's IP address, login is 'root'.

    • New
    Quote from kszaq

    In LibreELEC Settings enable SSH, don't disable password. Default password is 'libreelec'. You should be then able to connect with PuTTy by entering Pi's IP address, login is 'root'.

    Unfortunately the code did not fix it. I rebooted, installed the latest Nov 3 nightly, and still had no network settings.

    I had to throw the old working 19th update from USB stick into the update folder, reboot, and all is fine again.

    • New

    Thank you for testing. Please remember to remove the firmware overlay, so that in case this issue is solved by any update, your RPi loads a correct one from system image:

    Code
    rm -rf /storage/.config/firmware