Perl scripts to "test" the connection to the internet

URL: http://www.poirrier.be/~jean-etienne/software/testnetconnection/index.php

Last modification: January 8th, 2006

Goal

I was experiencing frequent disconnections of my internet link at home. I decided to check if my internet provider was correct and doing his job correctly.

My first idea was that there must exists free (as in free speech) and simple command-line tools to test the connection speed under GNU/Linux. As I am not a specialist, I tried to find such tools on the internet but didn't find any (if you have one, please feel free to share it with me - simple remove the "nospam" string). So I decided to write my own set of scripts in Perl.

History

Versions: 1, 2, 3.

Version 3: One single Perl script for everything

For this third (less dirty) version, I am still using the ping Perl object. And I decided to display and store the collected data. The final user doesn't need to worry about anything: the script automatically creates the data and graph files (filenames are based on the date/time when launching the script). The procedure is now very simple: just type "./traite3.pl"; that's all.

Here is an example of the resulting graph:

version 3 resulting graph

At the beginning of the Perl script, there are some variables you can easily modify before launching the script. They are the same as for the second version (except you don't need to guess the time it will take: the script will show you the maximum duration).

Now, there is only 1 program explicitly launched by the user and there are only 3 files. But there are still one problem: I still don't know if ping a good indicator for the connection speed (moreover, since my test PC is behind a router sharing the connection for the whole family, I am also dependent on the traffic generated by other computers)

You can download the archive script3.tar.gz with the Perl script (1.4kb).

Version 2: Perl script for the main effort

For this second (still dirty) version, I used the ping Perl object directly in the script. Since I want to be able to choose either to display the results or to write them to disk, I simply use a pipe to store data (one cannot see and write data at the same time). I added a random duration between each ping. Now the data text structure is changed, I am using another script for Gnuplot. The process can be summarised like this:

  1. type (you can stop the procedure at any moment but it should stop after the specified amount of iterations, see below):
    • "./traite2.pl" in order to see the ping results (but not save them) or
    • "./traite2.pl > test.dat" in order to store the ping results (but not see them).
  2. use Gnuplot (with commands in another script): "gnuplot script2gnuplot.inc" to draw the final graph.

Here is an example of the resulting graph:

version 2 resulting graph

At the beginning of the Perl script, there are some variables you can easily modify before launching the script:

  • $host is the hostname to check
  • $maxtimetowait is the maximum time to wait (in seconds) between each ping
  • $maxiteration is the maximum number of iterations ; with this, you can compute the maximum duration the script will take = $maxiteration * $maxtimetowait (in seconds ; $maxiteration * $maxtimetowait / 60 in minutes)

So, now, the data collection can stop by itself, ping isn't launched every second, we can measure time with more precision, there are less files used (4) and only 2 programs explicitly launched, we have parameters that do not mess with the code. But there are still some problems:

  • There are still lot of files used (4 in total) and 2 programs explicitly launched by the user
  • We cannot see and record data at the same time
  • I still don't know if ping a good indicator for the connection speed (moreover, since my test PC is behind a router sharing the connection for the whole family, I am also dependent on the traffic generated by other computers)

You can download the archive script2.tar.gz with the perl and gnuplot scripts (977 bytes).

Version 1: no Perl script (for the main effort)

For this first, quick and dirty, version, I didn't wrote any Perl script for the main effort. Everything was done by the "ping" command: ping results were collected in a data file with a simple pipe. I only used Perl to parse this data file, write data in 2 columns in another file. Finally, I used Gnuplot to draw the graph. So, the process can be summarised like this:

  1. command "ping www.xyz.com > testconnection.dat" to collect data ; I stop this command with Ctrl + C
  2. use of Perl with "./traite.pl testconnection.dat test.dat" to parse the first (text) file and write everything in the second (text) file
  3. use of Gnuplot (with commands in a script): "gnuplot scriptgnuplot.inc" to produce the final graph.

Here is an example of the resulting graph:

version 1 resulting graph

As you can see, there are still some problems:

  • The first command must be stopped by the user
  • The ping command is launched every second (it could be bad for the target host)
  • We cannot measure time with precision
  • There are a lot of files used (5 in total) and 3 programs explicitly launched by the user
  • I don't know if ping a good indicator for the connection speed

You can download the archive script1.tar.gz with the perl and gnuplot scripts (968bytes).

Comments and links

On January 7th, on my blog, Alexandre Dulaunoy gave the URL of a very nice free software for monitoring network connectivity: SmokePing. SmokePing is a deluxe latency measurement tool being able to measure, store and display latency, latency distribution and packet loss (so it's already more than this script can do!). It further uses RRDtool (by the same author) to store data and to draw graphs. It also supports smart alarms and dynamic IP.

Although also written in Perl, SmokePing works as a daemon process (+ CGI script to show graphs). Well, it was not my initial goal when I started my script: I just wanted something simple the regular user can launch and stop at will. SmokePing is much more powerfull but also needs more dependencies and more skills than my scripts. There is more than one way to satisfy your needs.