Posts by quickstang

    After nonstop playing around with NAS settings and google, I FINALLY figured out why the Pi wouldn't play anything from the multimedia folder and I kept getting the picture above.

    Under the QNAP NFS settings, the SQUASH options drop down box was set to ALL_SQUASH and when I changed it to NO_ROOT_SQUASH everything started working again. I realized that all of my IP settings were correct in the permission section, there were no settings in the Pi I could see, so I gave this a try. I decided to check other folders and noticed this one was not like the rest for the SQUASH setting. Not sure how it ended up changed, but when I changed it, everything in the multimedia folder now works again on the Pi.

    Only took me a whole week to figure it out. lol

    If you are granting access to NAS shares only to specific IP's and the RPi moves around the DHCP scope, you could:

    • Configure a static address in the RPi and then allow that address on the NAS
    • Create a DHCP reservation in the router for the RPi so it is always dynamically assigned the same address
    • Create credentials to access the shares and avoid the need for IP blocking

    IMHO using a DHCP reservation (makes SSH access to the RPi consistent) and also using credentials and basic access controls to manage access to shares is the winning combination. From a security perspective IP blocking is a fairly blunt instrument.

    I tried the 3rd option which took in router settings, but still no luck. I then decide to go back to regular default settings and no luck there either. The IP address in the Pi is the same I added to the shared folder in the NAS. Usually as soon as I add the IP address the movies start working again.

    However I am getting the picture attached. Rebooted the PI, then the NAS as well, double checked I applied the settings when I added the IP address to the shared folder. Only other change is the nightlies. I wouldn't think that would be an issue, but I can try and downgrade to a previous version to see.

    I also know the files are still available because I checked the multimedia folder in the NAS and everything is still there. So I have no idea why the PI is suddenly not seeing the folder. Especially since I added the IP address to the shared folder.

    So I have a QNAP NAS, and for some reason I have noticed recently that on occasion my Pi keep changing IP addresses. And when it does, I have to take that new IP address and add it into my NAS settings for it to see the multimedia. Is there something I should be changing on the PI to prevent this from happening, or is this something I need to fix in my EERO router? Granted I haven't changed any router or PI settings, but it appears to happen more frequently than before.

    It works on Chrome on the laptop, so it has to be something related to iOS Beta 26. Nothing has changed except that on the iPhone as I was going to the nightly build page daily. Why the nightly build page crashes, I have no idea, because the forum works fine. Regardless if it's WiFi or 5G, the nightly build site does not work on any phone web browser. I have tried 4 of them. But again, why an OS update would cause this for all web browsers, no idea.

    I borrowed RPi4 to check a few things. My instructions to replace the firmware were not complete - you also need to create a symlink pointing to the firmware, depending on whether you're using RPi4 or RPi5.

    A workaround for the latest nightlies is:

    Code
    echo options brcmfmac feature_disable=0x400000 > brcmfmac.conf

    This disables "External auth" feature. Note that WPA3-only network will not work but you should be able to connect to a WPA2/WPA3-mixed network.

    Should I run this on a working nightly then install the newest? Or should I just install the latest nightly, then run the code?

    Also, is that code the only code that needs ran, or do I need to run it along with the other commands you mentioned in your prior post?

    Thanks!

    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.

    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.

    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.

    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?

    My network also shows State: ready, and Type: auto under connection settings along with IP address.


    I do have IPv6 set to on for my eero router as seen in the picture. It has always been on and again, no issues with any nightly up until that IPv6 change it appears.


    kszaq I myself personally do not have firewall set to on for the Pi under the network settings.

    If there's an issue it seems to be localised to your environment. I'm running a (self-built) nightly image on an RPi5 without any network issues and lots of other people run nightlies too; enough to flag-up any general networking issues. NB: The kernel changes in question will be irrelevant unless your home network is IPv6 based?

    I'd start with a clean LE13 nightly image on a spare SD card. Any different?

    Yes, the network does have IPv6 on.

    Tested a clean build of the latest nightly and there were no network settings there just like the pictures in my first post.