[BUG] Invalid-key while connecting to wifi - LE11 #7166
Comments
|
Same issue here, seems to have gotten worse with versions >nightly20221128 |
Are you having the issue with LE10 or LE1 nightlies? |
LE11 |
Hard to compare LE10 and LE11 (we shouldn’t)
For le11 please check with > 20221213 - as this is the new kernel (check in dmesg for kernel 6.1) and includes the Kodi rc1. We will need the logs etc … |
|
Inactive issue. Please reopen if still an issue and with updated information (using latest LE11 nightly.) |
|
I encountered this issue today with the latest LE11 nightly (f4f7d8e). I ran it on a Pine H64 Model B, so it seems that this issue is affecting more hardware platforms than just the Raspberry Pi 4. If you reopen this issue, I'm willing to provide any debug logs you need to troubleshoot this; just guide me through what I should do. |
heitbaum
changed the title
|
Updated as LE11 issue (which uses iwd) |
|
On last Nightly build, stop and restart wireless connection in parameter allow connecting to Wi-Fi. If that can help someone |
|
The solution from the LibreElec forum appears to works:
|
|
Why does this |
|
I'm not sure - but I'm pretty sure it works. When I ran into the issue after upgrading to LE11, I rebooted, wiped the wifi settings, etc without result. Eventually I found that thread, applied the setting, and now it works and it keeps working even after reboots. edit: No, now it broke again. It just seems that the wifi failure is completely random. |
|
I tried the |
Same here. I need to persist the logs to SD card though, as I don't have a wired connection where it reproduces and I can't reproduce it where I have a wired connection (because I'm near a different access point that doesn't exhibit the issue). |
|
I tried to figure out troubleshooting steps and perhaps I'm adding more noise to to this issue than actual value, so take the below with a huge grain of salt. In the ArchLinux wiki I read that iwd can sometimes come online too early, so I tried to add a systemd unit that simply calls /usr/bin/sleep. This didn't have any effect. You can also run iwd in debugging mode, so that's what I tried next. For this I ran these commands: systemctl stop iwd.service
STATE_DIRECTORY=/tmp/iwtest
export STATE_DIRECTORY
mkdir -p $STATE_DIRECTORY
/usr/lib/iwd -dThen in another SSH session, to attempt to connect to a wireless network:
Then I can see in the other SSH session: The "network_autoconnect" happens for any network, but the network I just tried to connect to shows "No suitable BSSes found". I can't determine whether this is of any significance. I also cannot find any other debug tracing or apparent messages of importance. |
|
Are you able to test your case with IWD v2.4 ? |
|
Please retest with iwd2.4 - LibreELEC-yyyyy-11.0-nightly-20230329-a0f002b.img.gz (or newer) from https://test.libreelec.tv/11.0 |
|
Unfortunately still the same issues, same symptoms (invalid key, input/output error). Tested with:
And Raspberry Pi 4. For those who want to try, add "https://test.libreelec.tv/" as alternative update channel: And pick a release: |
|
@Sebazzz good to know. I see a couple "debug" method - the first one looks to get the right information. For your SSID - "Skynet" can you please share what type is it ?
Some questions / feedback - complicated / simple / special character PSK?
From my use
|
So apart from the WPA3 - that is the same as here. Going to 🤞for a positive outcome, otherwise it’s back to debug… and having to work with iwd/conman teams. |
|
Here's a brief update from my side: I tried LibreELEC-H6.arm-11.0-nightly-20230328-a0f002b-pine-h64-model-b.img.gz but I'm still experiencing the |
|
did you delete all old wifi directories within /storage/.cache/connman ? or older config files? |
|
If you are going to test with a fresh card - I'll compile 2 images for you.
I would first start with turning off ALL of the settings: "Band Steering" through "Multicast Enhancement". These are all fancy settings (and whilst are all standards - hopefully this is where we uncover the issue.)
Images should be ready in the next 2 hours. Link to Unifi settings: https://evanmccann.net/blog/2021/11/unifi-advanced-wi-fi-settings |
|
Alright, this is where we're at with settings. |
|
if you set the check box for fast roaming
https://heitbaum.libreelec.tv/
Other image is building now |
|
Ok off the bat, turning Just the Fast Roaming (802.11r) back on caused the original 12.0.0 Pi to return Invalid Key. The same symptom is observable with the fresh LibreELEC-RPi2.arm-13.0-devel-20240911070109-7a58fed image too. |
|
https://heitbaum.libreelec.tv/
So if the iwd team have indeed fixed the FT issue we are seeing - then it should be fixed in this image. |
|
No dice. Also when i tried to connect to the network on the OOBE/First run setup, KODI froze and restarted. the option did not come up the second time, only the enable services screen, Had to go in to settings through the main interface and select the network the normal way - Still shows invalid key with the FastRoam on. |
|
So when you disable FT on the unifi - does wireless work correctly with the 20240911074922-8081b71? (I was hoping that iwd-2.21 would address the lack of capability in the BCM chip, thus allowing the FT to be skipped.) There is an older article that talks directly to that FT is not supported on the RPi3 https://www.spinics.net/lists/hostap/msg07326.html By correctly - I’m asking if it “works” mostly. So we can continue the drill down on what options do not work. Once the “this works” this “doesn’t work” and some research on https://lore.kernel.org/linux-wireless/ then I think reaching out to the iwd dev community to get the right debug info. So far what we are saying:
I wouldn’t get to hung up on LE not working 100% correctly on OOBE as we are in the middle of alpha testing of Kodi. Whereas the Operating System major changes are mostly complete, we only have a major update of the kernel in planning once the years LTS kernel is ready (likely to be 6.12.) |
|
I systematically tested all the 'may cause problems' settings and went through one at a time, waited for settings to apply, Re-connected the Pi a few times. Below are my observations.
LE 12.0.0 |
|
Need to check the journalctl - what card is in both? Is it the same? Errors, output? Test by swapping the SD cards? LE12.0.1 is running kernel 6.6.45 (same as the LE13), iwd 2.19 There also is a reported “wireless strength” making things work in investigations todate. Did you by moving the RPi “fix that issue?” |
|
Reported strength is -70db or higher, as the AP's are all within (human visible) range of the devices. So right off the bat with the testing image, with 802.11r enabled, I see this in the serial console on bootup |
|
Oh, and no, The other Pi was happy again back in its normal place i think it just needed the 'Off and on again' treatment, though based on the above i wonder too if iwd just crashed while i was changing settings (Hence rebooting fixed) So that's a possible red herring. with 802.11f Off, both devices seem content in connecting, that seems to be the only setting that causes problems so far. I might just ignore the rest of those settings, the default is for them to be off anyway, Band steering and BSS are the only on by default settings and neither of those seem to be causing any problems. The network isn't really dense enough to warrant the other fancy options in reality i think. 802.11r maybe? |
|
if you have the core dump - it would be good to run gdb on it (as it shouldn't core dump) maybe part of the change that was made in 2.21. The cores will be located in
we may need to generate a debug binary depending on what it shows. |
|
|
IWD Core Dumps.tar.gz |
|
Here is an image with iwd including its debug symbols, so we should see a better backtrace. LibreELEC-RPi2.arm-13.0-devel-20240911125647-cf72d84.img.gz |
|
|
2 more changes in the image linked
can you please confirm if you get a core dump is newer than the iwd (might be a Timezone thing) https://heitbaum.libreelec.tv/ |
|
|
Not sure why this is closed , is it supposed to be fixed in LE 13 nightlies ? Got RPi4 (LE 12.0.1) , positioning the device near the router , wifi is working just fine. Installed latest Raspbian Os on the device , wifi is working just fine and with good speeds (both near and other room location) So the issue is clearly a software issue , messing with the AP settings helped abit , but still with raspbian OS everything is working just fine without any need to tweak the AP settings (lowering security for other devices mainly) |
|
This is a rant and those who are easily offended shoud not read it. This bug has nothing to do with router's settings, wifi drivers, kernel, devicetree, or any other settings. You can't fix it that way, so stop wasting your time (or anyone else's time for that matter)! It is exclusively caused by iwd returning a wrong error message (invalid key) when the wifi auth fails for other reasons, most common due to lost/corrupted wifi packets*. It happens when the signal is weak or there is radio intereference. The only way to make it better is to improve the signal. Or fix it permanently by using a goddamn cable! *It might work properly on Intel cards, since that was iwd's initial purpose. I can't test; I don't have any Intel cards. To make things worse, LibreELEC erases the key when receiving that error message -- which is the wrong thing to do even if it really is a bad key. This forces the user to re-type the password from the start, usually with the on-screen virtual keyboard and a TV remote control, while the typed characters are hidden! Usability is atrocious. Most TV remotes via CEC skip or double typed characters and those ******* in the password field are very difficult to even count. Iwd will not get fixed soon, if ever. It's been years since this bug was discovered. There is no discussion about this on other OSs forums and bug trackers probably because those OSs don't erase the key when iwd reports the wrong error. Just hit "connect" again (with the mouse instead of a TV remote!), or simply wait, and it will succeed with the same key. LE will also not get fixed soon, if ever. The devs insist they can't reproduce the error -- as if that matters. What are they gonna do? Fix iwd over the weekend and do a pull request upstream?? Hahaha. Fixing that means iwd must differentiate between a failed auth due to a bad key and a failed auth due to a corrupted packet containing the key. That will probably requre fundamental changes in iwd's design. That's months of work and no upstream will merge a PR like that. At this point, the only hope is that someone would fork LE. |
|
I second that.
Am 2. Oktober 2024 20:16:06 MESZ schrieb Marius Dinu ***@***.***>:
This is a rant and those who are easily offended shoud not read it.
This bug has nothing to do with router's settings, wifi drivers, kernel, devicetree, or any other settings. You can't fix it that way, so stop wasting your time (or anyone else's time for that matter)!
It is exclusively caused by iwd returning a wrong error message (invalid key) when the wifi auth fails for other reasons, most common due to lost/corrupted wifi packets*. It only happens when the signal is weak or there is radio intereference. The only way to make it better is to improve the signal. Or fix it permanently by using a goddamn cable!
* It might work properly on Intel cards, since that was iwd's initial purpose. I can't test; I don't have any Intel cards.
To make things worse, LibreELEC erases the key when receiving that error message -- which is the wrong thing to do even if it *really is* a bad key. This forces the user to re-type the password **from the start**, usually with the on-screen virtual keyboard and a TV remote control, while the typed characters are hidden! Usability is **atrocious**. Most TV remotes via CEC skip or double typed characters and those ******* in the password field are very difficult to even **count**.
BT keyboards double or miss characters too, but BT (on rk3288 at least) hasn't been working since... let me think... oh, yeah, since v10 too, same as 3D stereoscopic video, same as... I should probably stop now.
Iwd will not get fixed soon, if ever. It's been years since this bug was discovered. There is no discussion about this on other OSs forums and bug trackers probably because those OSs don't erase the key when iwd reports the wrong error. Just hit "connect" again (with the mouse instead of a TV remote!), or simply wait, and it will succeed with the same key.
LE will also not get fixed soon, if ever. The devs insist they can't reproduce the error -- as if that matters. What are they gonna do? Fix iwd over the weekend and do a pull request upstream?? Hahaha. Fixing that means iwd must differentiate between a failed auth due to a bad key and a failed auth due to a corrupted packet containing the key. That will probably requre fundamental changes in iwd's design. That's months of work and no upstream will merge a PR like that.
At this point, the only hope is that someone would fork LE.
And this is my final comment. You won't see me again.
--
Reply to this email directly or view it on GitHub:
#7166 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
|
While @pilian seems to make general sense in summing up things (in his on way) , whats still left a mystery (at least for me) is placing the same RPI4 device on same location with latest raspbian and not only there are no key/connection issues, the iperf3 (reverse mode of course) performance is also much better. Getting about 15-20 mbits at best using LE but 90-110 mbits on raspbian OS. (same location same router). Tested on another RPI4 device , exactly same result. So again , it is a software issue , not a hardware one. I can help debug/test the issue if needed , currently i am using an old router as "wifi bridge" to use the RPI4 device with ethernet. |
|
@hagaygo In my testing I came across a similar discovery with my PineH64 device: #8731 (comment)
It looks like simply replacing the device tree blob file in LibreELEC with the one from Armbian was enough to resolve the issue for my particular device. It's possible that a similar situation is present for RPI4. Try copying the device tree blob from Armbian and replacing the respective file in your LibreELEC. I'm interested if this resolves the issue for RPI4, which would allow us to hone in on the issue by comparing the device tree differences between Armbian and LibreELEC. |
|
I am comparing to raspbian (raspberry pi os) so i assume you mean to copy the dtb file from raspbian (and not armbian). Comparing the file bcm2711-rpi-4-b.dtb LE 12.0.1 56,056 bytes Raspberry pi OS 56,112 bytes So you suggest i copy the file from raspbian os to LE ? any other files or just this one ? Thanks in advance |
Yes, sorry I meant raspbian.
I copied directly from On LibreELEC, there is a
That was the only change I made which what made me realize that the issue was not with iwd but rather the device tree configuration on LE. |
|
Tried both copying the bcm2711-rpi-4-b.dtb file from rpi os and the fdt one after boot (the fdt one was bit larger is size tough no other file matched the size) Both booted fine but had same wifi behavior as the original one. To make sure i am replacing the correct file i renamed the bcm2711-rpi-4-b.dtb to bcm2711-rpi-4-b.dtbbbb and pi would not boot. So i guess its not the firmware file fault. |
The FDT binary being larger isn't too unusual because it can also contain changes made to the blob by the bootloader.
That's too bad. Unfortunately, with the invalid-key error message being so generic, it doesn't really tell us where the problem lies. It looks like for your RPI4 issue it's not the dtb, so at least we know that now thanks to your testing. |
|
I wouldn't at all be surprised if the network manager application in Rasbian is 'working around' the issue in some way that LE is not. Erasing the key on failure is the first indication to me of presumptuous software design, that is treating the errors as gospel and not as potential red herrings. It might be worth changing whatever front-end is controlling iwd on LE to assume the error is temporary and re-trying for a set amount of tries before giving up, but also not erasing the provided network key, because as we have seen, auth error could mean anything and not always that the key is bad, it should be up to the user to determine if they key is in fact bad and change it, or if the auth error is something else, removing the need to have to re-enter it every time something interrupts the connection (Which is bad UI design whatever way you spin it) this at least is the default behavior in 'Network-manager' the previously entered key is retained in the form for the user to reveal and verify, because wireless communication is not perfect, and sometimes S*t happens. |
|
This is still not solved from 2022?? |
|
Nice to see that this is still not getting the attention it deserves |
and others
Describe the bug
Hello :)
Since upgrading to LireElec 10 (10.0.3) the wifi is really unstable.
Every now and then, LibreElec will forget the wifi password and won't accept to reconnect because of some "invalid-key" error even tho the password
Other times it needs to try a few times before the connection actually is established.
To Reproduce
Steps to reproduce the behavior:
Informations
Log file
Additional context
What I tried :
I have two raspberries 4 with LibreElec, but having issues, so I don't think it's an hardware issue.
I also got an Odroid c2 which work flawlessly with the same wifi as the 2 other.
Even with LibreElec 9 there was wifi issues (failing to connect, without reason or because of input/output error) (for the two raspberries).
The text was updated successfully, but these errors were encountered: