I run OH2 on a Raspberry Pi v3 with Jessie, like many others do, but have an issue where if my Wireless AP reboots (its a Ubiquiti AP Pro access point) then comes back up again, the RPi doesn’t seem to reconnect to the AP. It’s as though, if the wireless connection is lost, it never even tries to reconnect. Of course, I can’t get to it to check its current state of what its doing (it sits in my cupboard, so have no console access either)
Is there a setting to tell the RPi to retry on wireless connectivity failure? At the moment, I have to pull power to the Rpi then plug back in.
@chimera
You shouldn’t pull power on the rpi it could damage the SD card and the linux kernel
You could use the network binding AND the exec binding
If connection is lost (network binding) the reboot the pi (Exec binding sudo reboot)
Yes totally agree, I don’t pull power from the Rpi unless I really have too. It’s not a regular thing, I just pulled power on the AP tonight because my daughter wouldn’t get off social media and go to bed thats when I remembered the rpi not reconnecting WiFi issue.
Thanks for the link, that prompted me to look further and I found another link below which I like better. Instead of a script running and sleeping for a minute, I think I prefer cron executing a script then exiting (incase the former terminates for whatever reason)
Thanks, I can see the watchdog daemon coming in handy, but don’t think it is suitable for this particular requirement. It can only do a system reset (under various circumstances) however a reboot is a little excessive if the AP connection simply gets lost - I’ll stick to the script that I posted above, I’ve tested and it works very well. Cheers
For reference:
The Linux kernel can reset the system if serious problems are detected. This can be implemented via special watchdog hardware, or via a slightly less reliable software-only watchdog
inside the kernel. Either way, there needs to be a daemon that tells the kernel the system is working fine. If the daemon stops doing that, the system is reset.
watchdog is such a daemon. It opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time
another minute. After a minute of inactivity the watchdog hardware will cause the reset. In the case of the software watchdog the ability to reboot will depend on the state of the
machines and interrupts.
The watchdog daemon can be stopped without causing a reboot if the device /dev/watchdog is closed correctly, unless your kernel is compiled with the CONFIG_WATCHDOG_NOWAYOUT option
enabled.
TESTS
The watchdog daemon does several tests to check the system status:
· Is the process table full?
· Is there enough free memory?
· Is there enough allocatable memory?
· Are some files accessible?
· Have some files changed within a given interval?
· Is the average work load too high?
· Has a file table overflow occurred?
· Is a process still running? The process is specified by a pid file.
· Do some IP addresses answer to ping?
· Do network interfaces receive traffic?
· Is the temperature too high? (Temperature data not always available.)
· Execute a user defined command to do arbitrary tests.
· Execute one or more test/repair commands found in /etc/watchdog.d. These commands are called with the argument test or repair.
If any of these checks fail watchdog will cause a shutdown. Should any of these tests except the user defined binary last longer than one minute the machine will be rebooted, too.
Actually,… the script above worked with a quick test last night. Doesn’t today - very weird.
I setup an eth0 IP and connected via the LAN as well. I then SSH’d via LAN, then pulled power to the AP. The wifi dropped, then by viewing the log, I saw the script execute, determine the network was down, attempted reconnection and showed that the wlan0 interface got its IP again. I had a constant ping to the wlan0 IP - it did not respond, even when the script said it was “up”. Then, about 3-5 seconds later, my ssh session to the RPi via eth0 dropped. I have no “network” access via either when I drop the Wireless AP (eth0 has an IP but no gateway, wlan0 has ip and gateway)
pi@raspberrypi:/var/log $ cat wifi_check.log
Starting WiFi check for wlan0
Mon Mar 19 16:14:01 NZDT 2018
Performing Network check for wlan0
Network connection down! Attempting reconnection.
Current Setting:
inet 172.16.221.250 netmask 255.255.255.0 broadcast 172.16.221.255
Pulled power, plugged back in, checked logs - suspect a possible hardware lock up - because no more logs for the wifi_check script were logged, and final entry in /var/log/messages was:
random: crng init done
Will have to research more…
EDIT: The below link was the issue for me, my kernel firmware was old. Doing a ‘sudo apt-get upgrade’ didn’t update firmware, so had to resort to an ‘sudo rpi-update’ instead… once that was done it fixed the lock up issue. Refer: https://github.com/raspberrypi/linux/issues/2435
thats when I remembered the rpi not reconnecting WiFi issue.