I will start off by saying, I am not really very knowledgeable about Linux nor PiAware.
I put my first feeder on in August, 2019, and have done a number of things to the improve it’s performance. Then as some of the things I tried had a negative impact, I decided to put up a test feeder I could make changes to with out affecting my main feeder.
I put my test feeder in my boathouse which does not have Ethernet connectivity. Seeing as the PiAware image supports WiFi I thought this would work very well. Set it up, and it worked great! Then it suddenly was not seen on the network. Rebooted the Raspberry Pi 3 B+, and everything worked great again, for a while. Thinking the Pi might be overheating, I got a case with a fan. The Pi would still disappear off the network periodically and randomly. I decided the Pi must be loosing connectivity through the WiFi. So I got to thinking and cribbed together the following script which is run as root by Cron. The corntab entry is
* * * * /home/pi/check-network.sh
So the script checks the network connection every minute. And if the Pi cannot ping the default gateway, it restarts the Pi’s Networking. And records the Network restart. If after a minute the default gateway is still not pingable, the script reboots the Pi.
My scripting skills are poor, but it seems to work for me. I have not had any outages of several hours since I got the script working the way I want several days ago.
The script listing is below.
#!/bin/sh
ping -c2 192.168.1.1 > /dev/null
if [ $? -eq 0 ]; then
echo .>/dev/null
if [ -e /tmp/NetworkRestartedOnce ]
then
rm /tmp/NetworkRestartedOnce
fi
else
if [ -e /tmp/NetworkRestartedOnce ]
then
cp /tmp/NetworkRestartTimes /home/pi/NetworkRestarTimes$(date +"%Y-%m-%d")
sudo reboot
fi
cur_time=$(date +"%Y-%m-%d %H:%M %Z")
if [ ! -e /tmp/NetworkRestartTimes ]
then
touch /tmp/NetworkRestartTimes
fi
echo Network Restarted: $cur_time >> /tmp/NetworkRestartTimes
sudo service networking restart
touch /tmp/NetworkRestartedOnce
fi
I use the linux watchdog daemon to keep a check on the pi - it can be configured to monitor network access among other things and run a repair script to try and fix it. It also monitors the pi’s hardware watchdog and reboots if it sees the system completely lock up.
As I said, I am not very knowledgeable about Linux nor PiAware. If there is a better way, I’m all for learning and implementing it. I put this post up because I did not see any previous post indicating how to resolve the issue I was experiencing and wanted to share the solution I had come up with.
If your script works ok and does what you want then no need to do it differently.
I’ll post my config for it when I’m home. It’s not too complicated though and there are a few guides around for setting it up on raspbian. You just have to make sure that you get the config right so you don’t end up with a reboot loop.
I notice the title now says the Wi-Fi intermittent problem has been resolved.
The Engineer in me says you have a work around but the WiFi problem still exists.
I have two Pi3b and a Pi Zero W all running on WiFi without any problems at all. Two of the 3Bs have been running for over 12 months without being touched nor restarted.
There does not appear to be a genetic problem with Wi-Fi and the piaware image.
I’ve had a similar problem with Raspbian Stretch, the WiFi connection would stop working but Raspbian wouldn’t attempt to reconnect.
Restarting dhcpcd always fixed the conneciton.
I’m not sure in what state exactly the WiFi connection was, but it was quite annoying.
Such things are almost impossible to debug, so a work-around might be the best option.
And if a problem is no longer a problem, it’s resolved
I had that issue when I was using an external wifi dongle with the pi 2 - something disrupting the wifi network such as a router reboot would mean that a restart was required to get it to reconnect. Restarting locally using the terminal worked as well, or via ethernet, but in use neither of those was practical. I assumed it was a crappy wifi driver for that particular dongle. I haven’t seen that issue since running buster.
The watchdog daemon is quite nice, since it lets you test for network connectivity both through pings and monitoring whether any data has been transmitted/received as well as quite a lot of other options - you can set limits for load averages, free memory, temperatures etc and you can make it get a fail condition multiple times before it reboots.
To get it to work, add the watchdog device to modules:
modprobe bcm2835_wdt
echo "bcm2835_wdt" | sudo tee -a /etc/modules
then install the watchdog daemon sudo apt install watchdog
then edit /etc/watchdog.conf
To get the hardware watchdog timer working you need
and the other tests can be uncommented and set as required. For example I have these options set:
ping = 192.168.0.1 # pings router to check for connectivity
interface = wlan0 #checks for data transfer on this interface
retry-timeout = 60 #retry tests a minute later to see if they persist before rebooting.
There’s quite a lot of options that can be set and I won’t list all of them. The documentation is quite good and explains what each one means though. You just have to think about what options you set so you don’t accidentally trigger reboots when you don’t need them.
And look how well that worked for Boeing and the 737MAX.
MCAS was supposed to hide the instability caused by the bigger engines. They thought that the problem was no longer a problem and that it was resolved.
