6

(I was trying and trying for hours to find a workaround, which proved much harder than initially expected.)

The problem itself is easy to understand, though. I recently installed a GUI-less Debian derivative on one of my machines and configured /etc/wpa_supplicant/wpa_supplicant.conf to access one of my access points and that worked out well.

Soon I took my machine with me out of home, so I added another network (which is my phone in hotspot mode this time) to wpa_supplicant.conf. Sadly I noticed that it doesn't automatically connect to the phone's AP even after losing connection to the inital router, followed by wpa_cli --reconfigure. Funny part: uncommenting the first network in the wpa_supplicant.conf makes my phone's AP work flawlessly. If both networks are kept uncommented, only the first one works.

I was reading the whole manual of wpa_supplicant.conf but the closest thing to what I needed was the BSSID option which didn't help in this situation.

So my question: how do I make the network controller change access points depending on availability of these?

Update: I don't have /usr/share/doc/wpa_supplicant/README.modes, but only /usr/share/doc/wpa_supplicant/README.modes.gz which I am unable to extract because of too many symbolic links.

My /etc/wpa_supplicant/wpa_supplicant.conf:

country=DE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="Klaus B. Schuldiger"
scan_ssid=1
psk="----"
}

#network={
#ssid="Xperia XZ_acd9"
#scan_ssid=1
#psk="----"
#}
GAD3R
  • 63,407
  • 31
  • 131
  • 192
Akito
  • 548
  • 1
  • 7
  • 17
  • You are using wpa_supplicant in roaming mode? (see `/usr/share/doc/wpa_supplicant/README.modes`) What does your configuration look like? What does `wpa_cli status` show after losing connection to the initial router? – dirkt Mar 13 '17 at 20:17
  • I can't check the `wpa_cli status` after lost connection because I control the system exclusively over SSH. And I don't know anything about a roaming mode. – Akito Mar 13 '17 at 22:21
  • That looks like roaming mode if the only entry in the `iface` stanza of `/etc/network/interfaces` is `wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf`. "Too many symbolic links" sounds that maybe something went wrong while installing the package, maybe try to reinstall it. You *should* be able to read this file with `zless`. Googling finds [online copies](http://biofisica-35.unipv.it/cgi-bin/dwww//usr/share/doc/wpasupplicant/README.modes.gz). – dirkt Mar 14 '17 at 07:10
  • Do you mean by "you control the system exclusively over ssh" that this is ssh over the internet and then over WLAN, the system isn't physically near you, someone else carries it around (so it looses connectivity to the AP), and you can't do anything on the system after you loose connection? If yes, this will be *really* hard to debug. Any chance you can get access to it physically for a short time for debugging purposes? – dirkt Mar 14 '17 at 07:13
  • Thanks, for your input, first I will check out the roaming thing. And no, it is right next to me but it is a big deal to attach it to all peripherals again, especially considering this "problem" shouldn't even exist in the first place. But of course, if nothing else works out remotely, I will debug it properly. – Akito Mar 14 '17 at 07:15
  • Okay, seems like I already have to attach everything again, anyway, since adding the value *ap_scan=2* now broke the whole connection. – Akito Mar 14 '17 at 07:18
  • Don't mess with `ap_scan` (and I don't think you need `scan_ssid=1`, either). Just make sure you have `wpa-roam`. If it got an ethernet port, just SSH in via LAN, then you don't have to attach stuff. – dirkt Mar 14 '17 at 07:21
  • The device is a Raspberry Pi Zero W and doesn't feature any LAN-ports. I use hidden networks and the tutorial for wpa_supplicant recommended to use scan_ssid=1 for that situation. It worked out without it, but then I still added it when the issues with the second one had begun. – Akito Mar 14 '17 at 07:24
  • The hidden networks could definitely be the problem: You need an active scan if the AP doesn't send out a beacon. One way to make sure it's the hidden networks which cause the problem is of course to temporarily make them non-hidden, get it to work, and then try to make it work with hidden APs. I've no experience with hidden APs (because they don't add security: any traffic between hidden AP and a client can be sniffed, so it's not really hidden...), so I can't help with those. – dirkt Mar 14 '17 at 07:27
  • Tried unhiding and hiding again every time I tested new possible solutions. It doesn't caus any problems. – Akito Mar 14 '17 at 07:28
  • The problem is: "WLAN looses connection -> the other, hidden AP is not in the list of passively scanned APs, because it needs to be actively scanned -> wpa_supplicant does not try to access to the hidden AP, because it doesn't know it's there". In other words, exactly what you are seeing. If hidden APs don't cause problems in other circumstances, that's not relevant. wpa_supplicant needs to actively scan for *all* hidden APs, and I don't know how to configure it do that. – dirkt Mar 14 '17 at 07:33
  • (Which doesn't mean it can't be configured to do that, just I don't know the details). – dirkt Mar 14 '17 at 07:34
  • It is not the problem about being hidden. I made both visible now and this changes nothing. But I discovered something new, that seems to me more like all this is steering towards an actual bug: I attached everything again, removed the *ap_scan=2* parameter completely and ran `wpa_cli reconfigure`. Now long story short: everything is as crappy as before, but THIS TIME it preferres my phone instead of my router. It is literally the same issues as initially, but this time the APs are swapped. Bug? – Akito Mar 14 '17 at 07:38
  • I apologize. The problem was indeed the hiding. The reason, why I didn't seem to find a difference when making them visible is, that it takes like 5 minutes to reconnect. I usually only waited like 2 or max. 3. You should answer this thread, so I can mark your solution as working for future generations. – Akito Mar 14 '17 at 07:48

1 Answers1

2

To debug what wpa_supplicant is doing, wpa_cli status will give information about whether wpa_supplicant still thinks it's connected to an AP, or searching for a new AP.

Wpa_supplicant needs to be in roaming mode to automatically switch between networks. You enable roaming by using a wpa-roam entry after the iface stanza in /etc/network/interfaces, and put all the networks in a wpa_supplicant.conf file (typically /etc/wpa_supplicant/wpa_supplicant.conf). Details can be found in README.modes or README.modes.gz in the wpa_supplicant documentation.

Hidden access points (APs) will cause trouble for two reasons: One the hand, wpa_supplicant will be need to actively configured to scan for all of them (and I don't know the details on how to configure that). On the other hand, the WLAN client will have problems to determine if the connection is still valid or not, because the AP doesn't send out beacons which could be measured. So all the client sees is no answer to transmitted packets, which could also be caused by problems somewhere else in the network. The client will timeout the connection eventually, but that can take several minutes.

Also, hidden APs don't really improve security: Traffic between a hidden AP and a client can be sniffed, giving away the existence of the AP. A client actively scanning for an AP also gives away the existence (and as it's actively scanning for all hidden APs it knows of, it gives even more information).

So the easiest solution is to make all APs non-hidden in case they cause problems.

dirkt
  • 31,679
  • 3
  • 40
  • 73