WiFi 'Invalid-Key' on LibreELEC 11/12 (inc. workaround)

  • Ok, Ok, I'm playing with words here. I said fixed, not a solution.

    More specifically, I have identified the sequence of commands to run so that you will never see Invalid-Key again.

    Still there are a few things going on here and first and foremost, I believe the problem with Invalid-Key I am having relates to my 10-year-old NightHawk R7000 router running FreshTomato Firmware 2024.1 K26ARM USB AIO-64K with Linux kernel 2.6.36.4brcmarm and Broadcom Wireless Driver 6.37.14.126 (r561982). My settings ('Advanced'-->'Wireles') can be seen here.



    Additionally, the Invalid-Key issue was particularly heinous because I have a half-dozen storage-*.mounts in /storage/.config/system.d/. They attempt to start/mount prior to autostart.sh. Of course they are bound to network-online.service. So, I made sure that they were defined with BindsTo=network-online.target. Still on LE 11.0x I would sporadically get the Invalid-Key. I would more often need to restart LE and as a result not have my storage mounts mounted and then need to reboot again and again, until I could connect. I have addons, backgrounds, favorites, iconds, backups, and more mounted this way so when this happened, Kodi looked pretty gnarly. Barely useable and required a reboot and flip a coin if it connected this time.

    The problem persisted on LE 12.01 although admittedly significantly less. I played around with connmanctl, and in time noticed the errors that made me look at my router. Again, its FreshTomato and honestly I can't find anyone who knows what all that crap on 'Advance' --> 'Wireless' page of the FreshTomato UI means. So, I went to ChatGPT. The settings above are what it suggested for compatibility with a RPi5.

    Still, No love! Invalid-Key persisted.

    After more digging I realized my autostart.sh script really needed updating. I was explicitly enabling each of my storage mounts with 'systemctl enable' one at a time and figured it was easier to do something like, 'for m in $(find /storage/.config/system.d/ -iname storage-*.mount -exec basename "{}" \;); do systemctl enable $m; done'. It was then that I realized I could start them the same way. I had previously just been forcing a reboot.

    All this is what started me down the rabbit hole of connmanctl and iwctl. I'll spare you all the gory details, but below is the result of tinkering every night since Friday. In the process I discovered the Nightly build from 10.05.2024. Armed with it and the script below, I am connecting every time I reboot. I have NOT been able to get it to fail.

    Let me be clear, I get errors from my storage mounts about 50% of the time and I may still not be able to "automatically" connect during a reboot from time to time due to external factors like distance and noise or interference from other electronic devices with various other Wi-Fi tech. Or needing to reboot my router or something. But after every reboot I am connected each time.

    Also, manual disconnects and reconnects from within the LibreELE AddOn seems to be working. But I am not pushing my luck there because during all of the trial and error, there were times when the LE Addon wouldn't open for some odd reason.

    While I still believe the issue lies with my router's age and custom rom, I have been second-guessing myself about that because of the drastic swing in behavior of the script from LE 12.01 to LE Nightly's 10.05.24 & LE 10.8.24. My router isn't changing. Why is the behavior changing? Something relating to configuration or versioning in LE? Maybe.


    Anyway, this works for me, I hope it works for you. Here you are...



    NOTE: /storage/.config/connman_main.conf .. It doesn't work. I reference it and found that it worked to save my WiFi connection as a favorite and it would show up in a scan from the LibreELEC Addon and even I saw evidence in the script logs that iwctl couldn't find the SSID but connected anyway. So I suspect it was because of this file. Don't know but suspect it plays some role.



    [reserved]

    Edited once, last by serendrewpity (October 9, 2024 at 4:57 AM).

  • From a coding/development perspective this is a workaround not a fix, but it's interesting. Thanks for sharing.

    I have a suspicion the trigger for invalid-key is about signal strength and things on the 'radio' side of WiFi, with the problem being related to how retries are handled. As we know reverting to wpa_supplicant also consistently eliminates the issue; the crack things fall down is probably in iwd, although "it takes two to tango" so interactions between iwd/connman that need examining.

    The challenge is/remains: finding people with the code diagnostics skills to triage the issue, who can also replicate the issue.

  • Point taken, but I admitted playing with words here. I said fixed, not a solution. I don't have to repeatedly reboot to reconnect and map drives. I also don't see Invalid-Key when it doesn't connect. I will see Operation Failed or Input/output errors but not Invalid-Key. I've been using LE since version 9 (You've aged gracefully btw). I've always seen Invalid-Key. I just usually tolerate and work around it. Again, I admit, that is indeed what I am doing here. Working around it. But something in what I did has suppressed that specific error.

    However, since this all started on Friday, my router is 87 i.n.c.h.e.s away from the RPI5. Signal strength is 90+. Saturday night, while using 12.01, I successfully connected and set up LE during First Run. I even successfully connecting, a few times after that. At some point after that and a significant amount of tinkering, I could not get it to connect for anything. Not after a reboot, not after a reconnect, not after deleting the connection in LE addon and recreating it. Not from the terminal window. I didn't fix that. I only got it working again, by reformatting the SDCard and re-imaging LE. That's when found ``Nightly 12 - 10-05-2024` . With this build, on Sunday night, I rebooted 25x and it connected on first attempt (including mounting storages). All testing was done with only First Run 'vanilla' being configured. No addons added. No configuration changes. Not even changing the Country / Region / Rev settings in LE. I'm open to being the router and signal strength, I just don't see how, having experienced that. Because the only thing that changed before and after those (success and failure) sessions was my script and the version of LE I was running. So, I need someone to explain that to me.

    I'm not a developer. I can script. I am a Lead Engineer. I will try whatever you want.


    Wow, you're censoring 'inch(es)'? Wonder what a-hol3 made a necessity.

    Edited 2 times, last by serendrewpity: Merged a post created by serendrewpity into this post. (October 9, 2024 at 1:08 PM).

  • The forum sees a moderate amount of attempted pharma spam from human 'bots' that bypass whatever technological registration/login restrictions are implemented. It's occasionally annoying, but the list is effective and overall impact is low so it stays.

    Moving back on-topic: There's an air of mystery around the trigger conditions, but ultimately the probably-radio-side cause is less important than ensuring retries (or resets, or doing something like that) result in a connection. It needs someone to run iwd and connman in debug mode and then trace what's observed in logs (both are reasonably verbose and somewhat human readable) against the actual code, and spot where the code/logic breaks. I too script. I can pseudo-read code to a point, but not well enough for this issue. It's not just about reading logs through. It probably requires some patching to add "printf" reporting of values that are being moved around between services.

  • Ok, I reduced the autostart.sh script to bare minimum. This is the debug script. I left the CIFS storage mount files in /storage/.config/system.d/. Since the storage mounts are attempted prior to the execution of autostart.sh, this enabled me to more easily see if LibreELEC was establishing a connection or the autostart.sh script was establishing the connection. If LibreELEC failed to make a connection the storage mounts would fail with pretty obnoxious error message during boot up. No error during boot meant LibreELEC made the connection.

    That was my naming convention. Success or Failure zip files mean LibreELEC succeeded or failed.

    However, in combination with the script below, I could not get LibreELEC to fail to establish a connection using the Nightly Build from 10.08.2024. Every. Single. Time. I tried multiple times. At least 20x reboots. Not one single failed connection. Either the script made the connection or LibreELEC did. This basically means the script never fails to establish a connection because a) there is no check for an existing connection so it can exit. b) there is no retry logic in the script (aside from the retries built into iwd and connmand).

    I've attached the logs for your review. There is an 'invalid-key' in it though; so, it is indeed a workaround not a fix.

    Now, I just need to append a quick test for a valid IP Address and the line of code below and I am golden. My mounts will be established as well.

    for m in $(find /storage/.config/system.d/ -iname storage-*.mount -exec basename "{}" \;); do systemctl start $m; done

    Here's the abridged, debug version of the script:


    The stanza for 'journalctl' in the script is pretty slick. It captures every single command from 'iwd' or 'connmand' from the start of boot.

  • as a point of note - iwd and connman in LE12 nightlies are now the same as that in the LE13 builds. So, any testing with LE12 should be undertaken with the nightlies - and hopefully there is improvement in the support. There have been some issues that have been addressed in iwd.

    So any logs with a cause / resolution could be shared with the iwd/connman teams.