Is there a built-in way to configure wifi so that it automatically reconnects if it goes out of range and then comes back into range of the router?

Here's the scenario: You have a portable device built on a Linux single-board computer. It uses wifi to do stuff. You walk around with it during normal operations. But there happens to be a dead spot so it goes offline there. However, when you emerge from the dead spot, it doesn't come back online automagically.

Right now, I'm using a cron task to check if wlan0 has an IP address and if it doesn't, it brings wlan0 down and back up again. This works but it seems like a hack.

What kind of device are we talking about?
What version of Linux (and distribution) are we talking about?
Is Network Manager (NM) involved? If so, you should be able to set this in NM.

yes it does require a medium that has this support as the other stated : Network manager has a setting that says auto connect.

1 members found this post helpful.

Ok, more details: This is a Yocto Morty based system so no Network Manager. It's also a headless system so no user-interface to speak of.

But I did some experimenting yesterday that was interesting. I set up the single-board computer to run off a battery. One of the LEDs on there was configured to use the phy0assoc trigger so that I'd know when it went offline. I also set up a continuous ping to the SBC from my laptop. What I would do is put the SBC inside a microwave oven and closed the door so as to surround it with a Faraday cage thus blocking the signals. I could see the LED change as it went offline and verified that the ping timed out. Then I would take the SBC out of the microwave to see if it reconnected.

My office router is an Apple Airport Time Capsule. With this as the router, the SBC reacquired automatically and the ping picked up again.
However, when I ran the same test with a Linksys WRT1600AC router, the SBC went offline and stayed offline.

Google searching is pretty thin on this topic particularly when you weed out Debian, Network Manager, and non-systemd references. But what ended up doing is turning off wifi power management with "iwconfig wlan0 power off". Now the SBC on the Linksys router does reacquire automatically. I don't see any settings in the router that might suggest why this works though.

Comparing this to a cron job that brings wlan0 down and back up again, this is probably a better solution because the cron method might reconnect to a different router if you have more than one listed in the WPA supplicant configuration. At some point, I want to get one of those Eero mesh products or something similar to see how seamless moving around turns out to be.

Anyway, call this one SOLVED, at least for the moment.

i don't know what "yocto morty" means so this statement makes no sense to me.
but do you know that networkmanager has a fully functional command line interface? the gtk applet is just the cherry on the cake.

Link here https://yoctoproject.org/about
A linux for embedded with some hardware independence. I had not encountered it either.

so you're just basically black screen command line
or
connect to wifi command line

Not even that. This is a totally headless system. Think of it as a Linux appliance i.e. there's just a power switch (once it's configured of course).
The audience are non-technical people with zero Linux or command-line experience. You can also think of it like Amazon's Echo or Dot or Google's product. Internet of Things.

Also, Yocto uses Systemd so it doesn't use /etc/network/interfaces.

I've got it set up so that it serves up a PHP-based browser page off lighttpd to handle configuration of WPA supplicant configuration but once that's done, it's an appliance that needs to maintain connectivity as long as it can see one of the chosen routers. Note: it also runs Avahi so you can address it with a name instead of having to know what the IP address is.

wtf - give them a book and have them learn Linux ... quick fix

so its more like an embedded system flashed to a ROM and what you get is what is already there and no more.

if it is on a plug and play. whereas you take it to some place plug it in turn it on then it is just suppose to work.

that requires a internet connection
static IP so it can be hard coded into the system
But cannot be static if the system is moved to another access point outside of the original network that uses that IP address.

So it has to be dhcp IP and has to have the ability to look for an connect first, if found gain IP then connect

dhcpcd and systemd-networkd can obtain an IP address automatically via DHCP.

or by whatever means you are gaining wifi access already, then it could be put into a loop to run your connect to wifi command(s) within that loop then just add some code to have it check if no connection then reconnect if connected then sleep x=N

always assuming networkmanager has auto reconnect functionality, i still don't see why you couldn't install it on that device.
like i said, it has a fully functional cli interface, persistent configuration and service files and whatnot.
there's no gui dependencies.

802.1x/radius

To connect a wired adapter using 802.1x/radius you will need to specify some configurations and enable the necessary service for the adapter. This is useful for headless servers using networkd.

that is off that link I put in here....

Let me clarify:
Given that wpa_supplicant is already configured with at least one SSID and password. This is done initially by plugging in a hard ethernet cable to a port that has a static IP address associated with it so there's always a known way to get into the system (other than a system serial console which you don't want a novice user screwing with).

Networkd is set up for DHCP. That's all well and good if you happen to know the IP address that the router assigned. A consumer isn't going to know this which makes using Avahi pretty handy.

So at this point, the appliance is happily doing it's thing. Let's say that it's some sort of handheld environmental sensor that you'd walk around a large warehouse with. But that operating area has some wifi dead spots. Sure, the customer would be well-advised to improve their wifi coverage but you can't guarantee perfect coverage. And maybe one function of the appliance is to perform a site survey.

When the appliance loses connectivity, the user may still be walking around with it so it would eventually end up being back in an area of good signal with the router. If the device doesn't automatically reconnect, that's bad. Furthermore, let's say that you've configured wpa_supplicant with more than one SSID. If you simply have a cron task to check for an IP address and perform ifdown/ifup when it doesn't have one, it might connect to a different router. This is one reason why mesh router products like Eero are interesting.

like I said: you have no ability to click on anything it has to do this internally to check to be sure a connection is had, if no then reconnect ;; that requires a loop . because there is no way to tell it, it has to find out on its own.

the only way is to have do that is have it keep checking to be sure it does have a connection. when lost go into seek mode when found re-connect. that requires a loop

has it ia dhcp auto IP Address the only draw back would be if a password is needed that has changed. Because you can hard code one in.

then again you can write it to get the NAME of the connection then have a list that is hard coded in.
something like that... so if the user has more than one wifi named provider in the building then it is already set up to accept anyone of them. the data information is needed ahead of time of course to be programmed into the "software"


Connecting with wpa_passphrase

Because of the process substitution, you cannot run this command with sudo - you will need a root shell. Just pre-pending sudo will lead to the following error:

have you looked at this page to try and figure out anything?
https://wiki.archlinux.org/index.php/WPA_supplicant

I just seems to me that this sort of thing should be transparent to the user like it is on a Mac or a PC or an iPad. There isn't a script running in the background to deal with this. For example, when I take my Mac to the office, it automatically connects to the router that I had previously chosen. When I bring it back home, it automatically connects to my home router.

As I mentioned earlier, I found that this particular SBC, distro, and wifi device & driver was able to reconnect to an Airport Time Capsule but it didn't reconnect to a Linksys WRT1600AC unless I turned off power management for the wifi adapter. That suggests that there's something about the implementation of the protocol that's different between the two routers.

As to implementing all of this, remember that the audience does not know Linux and should never have to access a command-line interface let alone edit a file to set things up.

Automatic detection and reconnect is the behavior I observe on my Linux laptops. This one is running Q4OS right now, and it connects without asking. If the WIFI router reboots, the laptop reconnects without asking when the WIFI returns without asking. It IS totally transparent to the user (unless I dig into it and LOOK for trouble.)

The question then is "what is different about this users setup, hardware, or configuration that prevents the WIFI reconnect from being automatic, and what can we do to recover that functionality?"!

Since the behavior seems to be different with different WIFI routers, that router is certainly implicated. Alas, I do not have that model to test against. It could be a simple setting on that WIFI device, but I am not the person to find that setting.