FlightAware Discussions

PiAware WiFi looses connection randomly - Work-round found

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
1 Like

You are missing the correct backticks:
Have some: ```

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.

:+1:
How do you do that? More details requested (step-by-step method).

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.

1 Like

:x: :x: :x: Dont want to try …

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.

S

Well, your router doesn’t misbehave.

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

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

watchdog-device = /dev/watchdog
watchdog-timeout = 10

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.

3 Likes

Thanks for step-by-step instructions. :+1:

Don’t forget to start the watchdog service after editing the config file.

sudo service watchdog start
sudo service watchdog status
1 Like

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. :wink: :wink:

S

1 Like

As I don’t seem to be able to edit the subject, I can not change it to work-around found. I guess it will just have to remain the way it is.

@geckoVN, I don’t know how you did it, but thank you for changing the subject of this thread!

This post was flagged by the community and is temporarily hidden.