wpa_supplicant error on wifi enable. #29
Comments
|
Have you previously connected to WiFi on your Kobo? KU reads whatever WiFi settings have been set in the Kobo interface. Other than that, I'm not really sure what's going on. I'm rather suspicious of @NiLuJe any ideas? |
|
I'm not aware of any peculiarities with WiFi and the Glo HD (a couple of KOReader devs over the years have had a Glo HD, so it's seen a fair amount of testing). |
|
I do get that same error message when nickel sets WiFi up on my H2O, but that doesn't appear to be fatal. |
|
I'm not familiar enough with wpa_cli to grok how to actually use that, but there appears to be a |
|
Ok, so a red herring then. I'll wait to confirm with @tmjwid that it isn't a lack of available credentials/configuration before trying to investigate further. |
|
My kobo has WiFi credentials and can connect successful. No matter what state my device is in (WiFi disabled, enabled no connection, WiFi enable with connection) I get the error. I did not create a toml file nor have I edited any config files yet. |
|
Oh dear, something appears to be very wrong. My H2O (now on 4.20.whateverthelatestis), also isn't connecting to WiFi Relevant bit of the syslog is: |
|
And here's what I got on stdout/stderr |
|
I'm still on the first 4.20 release, I haven't checked in KU, but it still behaved in KOReader. Will double-check on the latest 4.20 tomorrow ;). |
|
It looks like to me that the wifi drivers/modules haven't been loaded, but I'm not an expert. The reason I haven't noticed anything until now, is that my Forma is still on FW 4.19, and my H2O had wifi set to forced on in developer mode. It's when I disabled forced-on wifi that I noticed the issue. |
|
Ok, found the problem. Wifi failed to connect because the Why it ever worked in the first place I'm not sure. In previous firmwares, it must have been one of the environment variables already available. That's the only explanation I can think of. |
|
|
|
@shermp: That's... strange. It's definitely exported early by rcS (and as such KFMon). I definitely still have it on my end, and there hasn't been an rcS update in quite a while. :? EDIT: Yep, still there on 4.20.14622 |
|
Yeah, it is in |
|
My point being it's also in KFMon's env, as such you shouldn't need to siphon it at all o_O. It's definitely still there in stuff launched by KFMon: e.g., after NiLuJe/kfmon@11b6641 |
|
Ahh, that's why it worked. I haven't actually reinstalled KFmon after my H2O so rudely updated itself... |
|
So the issue seen by @tmjwid might be something else after all :( |
|
Ah, okay, now it makes sense ;). Because yeah, it isn't in the env for stuff launched via the udev loop0 trick ;). e.g., my SSH shell: Man, that LD_LIBRARY_PATH is whack as hell :D. |
|
It's a good idea for met to grab 'em anyway, in case KU isn't launched by kfmon, or your SSH. (Eg, just tried launching KU from telnet on my Forma. It did not go well...) |
|
@shermp: Definitely. Kept biting me on the ass with my USBNet toggle ;). |
|
Perhaps back to the original idea of inserting |
|
Here's a new, more instrumented It logs more wifi stuff to syslog, and logs the output of |
|
Sorry for lack of communication, I'm from the UK and had an early night. I'll take a look after work (my usb cable is power only and I do not have ssh set up) with the updated bash script. I can also provide a full syslog before and after, but from memory your log @shermp is very similar to mine in terms of network output. |
|
Just as a side note, there were wifi changes in this release. |
|
No problem, I'm from NZ, so, timezones. I'm used to it. The new script basically logs more stuff, and adds extra checks. Hopefully we can see exactly where it fails, and why. TBH, those checks and logging should have been there to begin with, but ah well. Basically, the new script should tell us whether the problem is with WPA supplicant, or a problem loading the wifi modules. As a sidenote, it's a shell script, not a bash script, as the Kobo does not use bash as its shell, but rather ash (I think, it's whatever BusyBox uses anyway). Any script with bash specific features likely won't work. |
|
Sounds good, I know that logging verbosity and exception tracking is a fine art. Haha old habits die hard! I'll hopefully call them shell scripts one day but living in gnu land teaches bad habits. |
|
Latest syslog from update shell script: |
|
Ok, that log tells me the wifi module loaded ok. Is there anything in the |
|
Just a bunch of Scanning and Disconnected states followed by my mac address for the device and a uuid. Nothing else. |
|
So in other words, wpa_supplicant never connected, and it doesn't tells us much useful :( |
|
Ok, it's possible to get a lot more logging out of wpa_supplicant, and might be easier to try that before an strace. In the The line should then read: That spits out a LOT more detail in the syslog. (EDIT: and by a lot, I mean over 250 lines a lot... perhaps trying with |
|
And actually, I doubt running an strace on wpa_cli will reveal much. It is just a tool to configure and obtain the status of a running wpa_supplicant instance. The only thing my script uses it for is a check to see whether wpa_supplicant is in a connected state or not. As a sidenote, and I hate being that guy, but have your restarted your Kobo? |
|
I have "powered off" my Kobo multiple times since I did the installation. I have not performed a factory reset though. I can try that if you think it'll help? The device had no evidence of it being previously modified and it came to me in a factory reset state. |
|
I figured you probably had, but just thought I'd double check. It's surprising how many unexplained issues can be resolved by a reboot :) I might suggest a factory reset as a last resort if we can't figure it out, but it sounds like it probably won't help :( |
|
Aye, shame it didn't work this time. I'll modify the debug logging verbosity on |
|
Sidebar: I also have a standalone strace binary available here if you don't want to bother with the whole shebang ;). |
|
Adding -d didn't really add any extra output to the logs, so will try -dd in a second. I have got it to work though via a workaround. Turning on "force wifi on" in devmode makes it work. |
|
Yeah, forcing Wifi works via dev mode works, but a PITA for long term use. If you forget to disable it, bye bye battery! |
|
Hmm, scan timeout on a Glo HD? That extremely vaguely rings a bell. @shermp: A retry might be necessary to work around this, IIRC. |
|
Yeah it's not really a great workaround. |
|
Sorry, delete the comment as it had personally identifiable info in there. |
|
Yeah, I knew that sounded familiar: koreader/koreader#4387 Might not be the exact same issue, but it sure sounds similar ;). |
|
If it's a wifi timeout, could always try changing by changing the |
|
40 didn't work, but 100 did. |
|
25 seconds!!!!! Really? |
|
I just put a really high timeout to be 100% sure this was the issue, it was. Will test smaller values now. |
|
Something must be very weird with the Glo HD. On my H2O, wpa_supplicant receives scan results in under a second: That's the main difference I saw in the wpa_supplicant log. At the same point, yours just started giving |
|
I modified the shell script to log on every count from the while loop, 49 times it took the first time, then 38 on the second attempt before it had the ip. I think anything over 50 will be fine, but it seems there is a weird issue with the Glo HD. |
|
Interesting, because the scan timeout is 10 seconds according to the wpa_supplicant logs. Is your SSID hidden by any chance? If so, maybe it tries scanning, doesn't find anything, then attempts to connect to whatever is defined in the config file? |
That error would be coming from |
|
Nope, SSID is visible. I do run on 2.4ghz with modified firmware (dd-wrt) but I also tired it on my works router which is just a stock linksys box and got the same results. |
|
If nothing else comes to mind, I can at least increase the timeout to give the Glo HD a chance. |
|
Does a second connection attempt finishes the scan any faster? IIRC, that's basically what we do in KOReader. |
How do you implement that? Do you execute a second time after a set timeout? Or some other method. Remember, a lot my wifi stuff is from koreader. The only thing I really added to the process was wpa_cli. |
|
I'm not quite sure how that would translate here, as we do that with an actual wpa_supplicant frontend, not wpa_cli (https://github.com/koreader/koreader/blob/master/frontend/ui/network/wpa_supplicant.lua & https://github.com/koreader/lj-wpaclient). |
|
Doh, of course one would use wpa_cli to reconnect :p if I can figure it out of course... |
|
Okay, the manpage is wonderfully unhelpful (Use the Source, Luke!), but |
|
Oooh, wpa_cli can run a script which can respond to events. From the man page: That might be a better way of achieving what I'm currently doing with grep. Or maybe not, as it would be happening in a different shell? I really need to investigate the wpa_cli man page some more. |
The online man pages for wpa_cli are most helpful. The contain a subset of the commands available compared to when I type wpa_cli -h on my kobo. They're not missing any commands, no sir! |
Hi there,
I'm running latest KU with latest kfmon on a Glo HD with latest f/w (4.20.14622).
Whenever it autoclicks connect and initiates wifi enable, I get at
wpa_supplicant failed to connectfollowed byWiFi did not enable (1). Aborting!Here's the syslog.
Mar 15 19:14:32 UNCaGED: Mounting onboardMar 15 19:14:33 UNCaGED: Mounting SD cardMar 15 19:14:33 UNCaGED: Enabling WiFiMar 15 19:14:35 wpa_supplicant[2894]: Successfully initialized wpa_supplicantMar 15 19:14:35 wpa_supplicant[2894]: rfkill: Cannot get wiphy informationMar 15 19:14:41 UNCaGED: wpa_supplicant failed to connectMar 15 19:14:41 wpa_supplicant[2895]: eth0: CTRL-EVENT-TERMINATINGMar 15 19:14:42 UNCaGED: WiFi did not enable (1). Aborting!My kobo has the google analytics patch installed (redirect hostfile) and kfmon and that's it. Any other information I'll gladly supply.
The text was updated successfully, but these errors were encountered: