There have been unwarranted reboots of the router by the original router watchdog. The exact source of the problem is not entirely clear. However looking over the code, it struck me that using a blocking (or synchronous) ping library to check the status of the Internet connection was not the proper approach. In this post, I will be presenting an example project that monitors if the Internet can be reached using the AsyncPing library by akaJes. Just about the same code will be used to patch the router watchdog.

The starting point for my example PlatformIO project is the ping_interval.ino example by akaJes. By luck, that sketch does almost the same thing as needed for an Internet watchdog. At regular intervals it sends out 3 pings to 3 sites. These are non-blocking operations; as soon as the ICMP requests are sent, control returns to the normal loop() function without waiting for replies from the pinged sites. When ping replies do come in, program flow is interrupted to report which site replied.

In the Internet watchdog, only a single ping is sent out at regular intervals. The host or target of the ping request is chosen in round-robin fashion. The absence of a reply from a single target host will not be construed as a network failure. Instead the Internet is deemed down when no reply has been received from any of the target hosts for a specified number of seconds. It seemed like a good idea to collect some statistics about the number of replies compared to the number of ping requests sent out. For debugging and information purposes, a report of these statistics is printed and targets that do not reply reliably are identified.

The example program also includes a user ping function because the router watchdog had such a function mostly for the purpose of debugging and checking that the ping targets were correctly specified.

Scroll down to the loop() function and notice how it does very little work. At each iteration, it checks the time elapsed since the last ping reply was received from a target host and if it has been too long, it prints out an alert. In addition to logging the situation, the router watchdog will reboot the router at this point. The loop() also sends a ping to a fourth (valid) or fifth (invalid) host at irregular intervals of 1 to 2 minutes to mimic use of the sendUserping routine and blinks the built-in LED every couple of seconds. The interesting bits are done in the background. Let's look at that.

Scroll up to the beginning of the sketch. Besides the Arduino library, three libraries are used. The ESP8266WiFi library to connect to the wireless network for access to the Internet, the Ticker library to run two timers: one to send out pings at regular intervals (define by the PING_INTERVAL macro) and one to report the sent and received statistics at longer intervals. The macro REPORT_INTERVAL specifies when this is done. In the router watchdog, longer intervals will be set. Finally, the AsyncPing library provides the object that sends and receives ICMP requests and replies.

The INTERNET_LOST macro specifies the number of seconds since the last reply to a ping request before the connexion to the Internet is deemed lost. Two macros define the parameters for establishing the reliability of ping targets. The first PING_SAMPLE_SIZE is the minimum number of ping requests needed before calculating anything. The second macro, UNRELIABLE (a value between 1 and 10), is used to calculate the minimum number of replies that should have been received from a reliable target. The function reportTargetStatus() will issue a warning if the percentage of received replies over the number of sent requests is below 10*UNRELIABLE. When the number of ping requests sent to each of the targets exceeds RESET_COUNTER, the sent and received statistics are reset to 0. With the values shown, this will occur every 10 days or so.

The last user modifiable macro is TARGET_COUNT which sets the number of target sites to which ping request will be sent. The array of host names, pingHosts, can contain URLs or IP addresses. They should point to leading Internet sites that will reliably respond to ICMP requests. Everything after should not need to be modified.

Hopefully the reportTargetStatus() and resetTargetStatus() functions have names that clearly show their purpose and are simple enough not to need explanation. The function setupTargets converts the strings in the pingHosts array into IPAddress objects and stores these in the targets array. If a URL or IP address is incorrect, the IpAddress object is not created. At the end the variable targetCount will contain the number of valid IPAddress objects in targets.

Four objects are created: two AsyncPing "pingers" and two timers. The timer targetPinger repeatedly calls sendTargetPing at regular intervals of PING_INTERVAL seconds. When invoked, the sendTargetPing function instructs targetPinger, an AsyncPing object, to send a ping request to the next target host and returns immediately without waiting for a reply. Again, this is why it is called asynchronous or non-blocking. If targetPinger receives a reply from a host to which it sent a ping request, the targetPingerCallback function will be executed. All it does is update the lastValidPing time and the ping received count for the host that sent the reply.

The sendUserPing function will be called by the user to send a ping request to a specific host. In this case two call back functions are defined: userPingerRecvCallback which reports on individual ping replies from the host as they arrive and userPingerFinalCallback which will be called when the user initiated ping request times out and reports on the ICMP packet sent and received statistics.

For the purpose of this post, there are two important parts to the setup function. The first part assigns the appropriate call back functions as handlers for the two AsyncPing objects. An AsyncPing object has two handlers: _on_recv called as each ping reply comes in and the _on_sent handler (perhaps not the best name?) called when the ping request times out or is completed. Which handler is set with the <AsyncPingObject>.on method is determined by the value of the boolean parameter named mode which is the first parameter of the method. When mode is true, the second parameter should be the call back function to assign to _on_recv. When mode is false, _on_sent is assigned the second parameter of the method.

In the second important part of the initialization code, the two timers are attached to the two tasks that must be done regularly: sending pings to target hosts, and reporting on the ping statistics.

Here is part of the serial output of the program.

As can be seen, the program carries with the two remaining target hosts when one of the hosts has an invalid host name. Each time a user specified host is pinged, the remaining free memory is printed to check for memory leaks. Because that oscillates between 50288 and 50320 bytes, probably depending on memory allocations done in the background, it looks like there are no leaks.

The example programs included with the AsyncPing library specified the call back functions as lambda function, also called anonymous functions. I chose to explicitly define the call backs. I find it easier to follow and cleaner. But then, I am not really familiar with C/C++. More than once in these page, I have said that Pascal, or more precisely, Free Pascal is my preferred programming language and it does not feature anonymous function (although that may soon change Anonymous functions are "planned" this year). If you prefer using lambda functions, I have included in the project archive a version with them: main.lambda. Note that the AsyncPing library is included in the local lib directory to make the example self contained. Download the project by clicking on asyncping_test.zip.

Right now I am rather pleased with this Internet watchdog and I will soon use it in the router watchdog. I wish to thank the author of AsyncPing for a very useful library.