(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:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev

ssid="Klaus B. Schuldiger"

#ssid="Xperia XZ_acd9"
  • 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, 2017 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, 2017 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.
    – dirkt
    Mar 14, 2017 at 7: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, 2017 at 7: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, 2017 at 7:15

1 Answer 1


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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .