Connecting to mesh network

[sladflob]

We upgraded to a Google Nest WiFi system over the weekend (jury's still out as to whether "upgrade" is the right word, but still) and I'm finding that KOReader can't connect to the new mesh network. It sees each of the three mesh points as three networks (each with the same SSID) instead of one, and if I try connecting to one it doesn't really work. If I drop out of KOReader and connect to the network using Nickel it works, and I can then start KOReader and check for updates etc., but it's annoying not being able to do it from inside KOReader. Has anyone else had similar problems?

[NiLuJe]

If it's stored as a "Saved network" in Nickel, you shouldn't have to click on anything, it should auto-connect to it. (At least for classic APs ^^)

In any case, syslog & crash.log output would be helpful .

[twowheels]

I have an Orbi mesh system, and my Clara HD (and all other devices that I have) can connect to it just fine, though I don't use KOReader and don't know if it does any networking of its own (I would assume that it doesn't, that it's the Kobo's OS that is doing the connection).

[sladflob]

Originally Posted by NiLuJe

If it's stored as a "Saved network" in Nickel, you shouldn't have to click on anything, it should auto-connect to it. (At least for classic APs ^^)

So I told both Nickel and KOReader to "forget" the network and started again. I started in Nickel, it discovered a single SSID for my network, I entered the password, and it connected no problem. Then I turned off the WiFi and started KOReader.

In KOReader, I chose Network, WiFi Connection and it asked me if I wanted to turn on WiFi. I said yes and it presented me a list with 3 entries for my home network's SSID in it and just sits there, doesn't automatically connect. I tried choosing each of these SSIDs and it prompts me for my password for each one (I didn't type it in, just backed out). So after I'd tried them all, KOReader still has WiFi turned off and hasn't automatically connect to my home network.

BUT, and here's the weird thing... if I try to do something that needs the network, say Check for update or look at my DropBox in Cloud Storage, it asks me if I want to connect to WiFi. If I choose yes, it briefly pops up the list of networks (and again I see three of my SSID in it) and then does automatically connect to my network (without prompting for password), does whatever action prompted the connection, and stays connected.

So is it possible that enabling WiFi via the Wi-Fi connection menu item gets confused when it sees multiple SSIDs?

In any case, syslog & crash.log output would be helpful .

I had a look in there but couldn't see anything but will collect and post them later.

[sladflob]

I couldn't resist but look at the code paths for the two cases in my previous post.

In the case where you manually attempt to turn on the network it's getting the list of networks in showNetworkMenu() via getNetworkList() and tries to connect to the first one that has a password set. Without debugging it, I'm guessing that none of the networks corresponding to the access points have a password set because it doesn't attempt to connect to anything.

In the case where it connects to the network when you try and do something else it just calls turnOnWifi() (which in my case is calling koboEnableWifi(1)), which I again assume gets Nickel or whatever to handle the network connection.

So I think there's something odd going on with the way the mesh network is being returned from getNetworkList() (or getSavedNetworks(), which it calls).

[pazos]

Hi sladflob!

KOReader uses the same daemon to connect to wifi that nickel uses: that's wpa_supplicant. Internally wpa_supplicant see three different APs. Nickel (and most other gui programs) just displays the AP with more tx power (usually the nearest) while KOReader is reporting the three. That shouldn't affect the behaviour of wpa_supplicant (ie: once connected it should roam fine between aps on both programs)

The code paths you mentioned are somehow platform specific and I don't have a kobo since a few years ago, so bear with me if I miss the point:

As far as I can remember, we will try to repurpose wpa_supplicant configuration from nickel. That's the original implementation. Years after that a proper discovery prompt was addded.

I'm afraid that your two code paths are triggering these two different behaviours and I *think* that you can try to remove "network.lua" in /mnt/onboard/.adds/koreader/settings. This way the second codepath shouldn't apply and, IIRC, nickel wpa_supplicant will be used.

Please keep us informed.

[sladflob]

Thansk for the info pazos! I tried deleting network.lua but unfortunately the problem persists. Actually, to be more precise, the problem occurs sometimes, roughly every second time I try to connect. I'm not sure if it's better than it was before as I don't think I tried it repeatedly. But what happens is that I tap "Wi-Fi Connection" and it asks me if I want to turn on Wi-Fi. If I say yes, the list of networks appears with my SSID in it 3 times and it just sits there. If I tap on the background to dismiss the list, then tap Wi-Fi connection again, I get the same list but all three rows with my SSID have "disconnect" next to them, and it actually connects. So this may be better than before, but why does it only work every second time?

I'm wondering if each of the networks returned by getNetworkList() has the password associated with it, or if only one of them does (the one the device was connected to when I entered the password in Nickel). Maybe if it obtains the networks in a different order the one at the top doesn't have a password so it doesn't connect. But then you'd think it would keep going down the list until it finds the one that does If I get time this week I might write a bit of code to log this.

[NiLuJe]

Fun fact: Both code-paths do the exact same thing ^^.

They both call `promptWifiOn`, which calls `turnOnWifi`, which calls `showNetworkMenu`, which then does the wpa_client stuff via our Lua frontend the exact same way in both cases.

(The only thing different is the connect_callback, which should be irrelevant here).

TL;DR: The manual prompt should behave exactly the same as the auto-connect.

Hence I'd really like to see what wpa_supplicant is doing behind the scene if that's not what actually happens (i.e., syslogs plz ;p) .

I have almost no experience with wpa_client's guts and behavior myself, but your final paragraph does sound sensible. And might explain the behavior you've seen (i.e., luck).

[NiLuJe]

Playing with wpa_cli in a shell and seeing what it has to say about that may be interesting, too .

(Fair warning: its documentation is *horrendous*).

[sladflob]

Originally Posted by NiLuJe

Fun fact: Both code-paths do the exact same thing ^^.

They both call `promptWifiOn`, which calls `turnOnWifi`, which calls `showNetworkMenu`, which then does the wpa_client stuff via our Lua frontend the exact same way in both cases.

But when I am prompted to turn on wifi via checking for updates or whatever I don't get a menu with a list of networks, it just seems to connect. When I traced through the code I found it eventually got to platform/kobo/enable-wifi.sh. Am I missing something?

edit: ok, I just realised it does briefly pop up the menu. Sorry, typing this while at work without a Kobo in front of me

[sladflob]

Originally Posted by NiLuJe

Hence I'd really like to see what wpa_supplicant is doing behind the scene if that's not what actually happens (i.e., syslogs plz ;p) .

Silly question, but what's the best way to get the syslogs? I take it they're not the syslog-2020* files in .kobo?

[NiLuJe]

@sladflob: if you have Devmode enabled, they are dumped in there every USBMS session.

But I find just running `logread` in a shell much less unwieldy .

[sladflob]

Originally Posted by NiLuJe

But I find just running `logread` in a shell much less unwieldy .

OK cool. Here's the relevant bits from the syslog for 4 connection attempts, one minute apart. The ones at 10:53 and 10:55 didn't work, while the ones at 10:54 and 10:56 worked. The ones that failed seem to generate a few WPA_SUPPLICANT messages but I don't really know what they mean.

[NiLuJe]

Hmm, That's... interesting.
wpa_supplicant seems to indeed get slightly confused by the fact that it can reach two BSSID w/ the same SSID. The first connection to the initial BSSID fails, it tries to connect to a second BSSID w/ the same SSID (i.e., another node in the mesh), and finally successfully connects the the *first* BSSID (??!) anyways.

Somewhere along those lines, our frontend gets lost, and assumes the association failed, hence nothing happens.

But the next time you try to connect, wpa_supplicant is already associated, so it just returns the currently connected network, and the frontend happily continues to obtaining an IP w/ DHCP.

(The mess of failures at wpa_supplicant startup is "normal" on a Kobo)

----

TL;DR: Attempting to connect *twice* should work mostly fine as a workaround.

Other than that, it'd need some digging into lj-wpaclient to figure out what's confusing the frontend, exactly (and/or if that's not simply a wpa_supplicanbt bug, because the BSSID jump is weird).

[sladflob]

Probably not mesh related but I'm posting it here just in case...

I updated my KA1 to 15505 today and now can't connect to wifi at all - I get the error "Failed to initialize network control client: Failed to connect to wpa_supplicant control socket: /var/run/wpa_supplicant/eth0."

I updated to the latest nightly (by first connecting to wifi in Nickel) and still have the same problem. Any thoughts?

Sent from my SM-T720 using Tapatalk