As said, if the system is at a static location with static WiFi AP, auto-reconnect is usually not needed, but only lengthens connection outage unnecessarily (from a fraction of a second up to a second or two).
Since in case of a truly headless or remote system, permanent network loss is extra nasty, an interesting experiment would be to setup an SBC with a temporary AP, like a mobile phone hotspot or so, and then disable that AP, and monitoring what happens in journalctl -u ifup@wlan0. Does e.g. wpasupplicant give up entirely after a while, or does it keep retrying to reconnect? Does it reconnect automatically when starting the AP again an hour later, or in the next morning? I could actually imaging it does, which would prove that auto-reconnect is really only needed for mobile SBCs to switch from one AP or network to another. ⌠and even for those cases, maybe modern wpasupplicant is clever enough to rescan for networks and attempt to connect to any in its configuration?
⌠basically it would be interesting to hear from use cases, where WiFi connectivity was really permanently lost, without using the auto-reconnect feature.
Hello, I havenât brought up this topic recently, itâs probably from two years ago.
@MichaIng Not that I think you took offense, but I wasnât criticizing your suggestion so much as I was honestly just laughing at myself. My first thought was âOh neat! I can just run those two commands via SSH instead of walking out there and rebooting the PI!â and then I realized that I actually couldnât because its unreachable 
.
For context, I stumbled across this thread because we have one Pi in deployment that has been regularly losing its Wi-Fi connection. Itâs the only one connected via Wi-Fi. Prior to finding this thread, I was unaware that DietPi is not configured to automatically reconnect by default. After the explanations given here, I now have a better understand of why that is. Weâre fairly certain that the reason behind the disconnects weâve observed are due to poor Wi-Fi coverage in the area where the Pi is installed. Thereâs that and the fact that its out in an area of a factory with lot of machinery and large amounts of metal being hoisted around by an overhead crane.
To be honest, weâll probably end up running ethernet out to that location eventually. When the Pi does connect, the transfer rates are so slow. In the meantime, Iâll consider monitoring what happens with journalctl -u ifup@wlan0.
No offense taken 
.
So in your case, when the WiFi connection is lost once, it remains lost, but bringing the interface down and up again restores it? If you have any chance to check journalctl -u ifup@wlan0 after such an incidence, that would be very interesting indeed. Happy to learn about what wpasupplicant does automatically in which situations, and what it doesnât.
What I know from here, when blocking the WiFi signal temporarily, or attaching an SBC far away from the AP, connectivity can be flaky, e.g. SSH hanging, or disconnect. But when moving closer again, resp removing the Faraday shield, I can reconnect immediately. But I didnât run many tests, and not for a long time, but just to confirm that a flaky WiFi signal does not automatically mean you need to use an auto-reconnect feature that restarts the interface as a whole.
The problem with such an auto-reconnect script is, that it is hard to distinguish between a flaky signal where a package can get lost by times but does not require an interface restart, and cases where it does require a restart for some reason:
- Currently, it sends a single ICMP packet only, and restarts the interface if that fails or it doesnât receive an answer. For flaky networks, this is too aggressive.
- It could send multiple packets, but
ping returns an error if just a single answer is missing, so that doesnât make it better.
- Weâd need to parse the output to know whether only some or all answers are missing. But another issue is that it raises the time each probe takes.
- Another way would be to call
ping itself X times in a shorter sub loop, and skip the network restart once one was successful. We could reduce the time until the next probe by the number of sub loop calls in seconds. But on a real connection loss, it increases the time until connectivity is re-established.
There is a GitHub issue about that: dietpi-wifi-monitor enhancement ¡ Issue #6907 ¡ MichaIng/DietPi ¡ GitHub
Hard to say what is the optimal solution without knowing the cases where it is really needed better. Hence for now, it is kept simple, without complex retry logic or additional options.