To summarize my coverage of the ping-verse, so far on the NetBeez blog, I have covered four different utilities: ping, nping, prettyping, gping. In this post, I am continuing with fping. And there is even more ping goodness coming your way soon…
Fping stands for fast ping, and its main differentiation with the regular ping is that it gives you the ability to scan a list of hosts (either coming from a file, an IP range, or a subnet) and tells you which ones are alive. Other than that, it can do pretty much everything the good old ‘original’ ping can do in terms of latency, configuring payload, IPv4/IPv6, etc.
Installation
Fping is available to install on Debian based linux with:
sudo apt-get install fping
However, I’d recommend to follow the instructions on the project’s github page here in order to download and install the latest version. Here is how I installed version 5.0:
git clone https://github.com/schweikert/fping.git cd fping/ ./autogen.sh ./configure make sudo make install
Basic Usage
The most basic task fping can do is tell you if a host is alive or not, as follows:
$ sudo fping google.com google.com is alive
As you can see it doesn’t even return the latency. Note that you have to run fping as a root user.
To get the continuous pinging functionality that the regular ping does by default you have to add the-l flag as follows:
$ sudo fping -l google.com google.com : [0], 64 bytes, 6.94 ms (6.94 avg, 0% loss) google.com : [1], 64 bytes, 6.91 ms (6.92 avg, 0% loss) google.com : [2], 64 bytes, 6.94 ms (6.93 avg, 0% loss) google.com : [3], 64 bytes, 8.29 ms (7.27 avg, 0% loss) google.com : [4], 64 bytes, 6.92 ms (7.20 avg, 0% loss)
The reason fping is called “fast” is because you can specify the interval between the ping packets down to the millisecond with the-p flag. To demonstrate this I am adding the-D option that prints the timestamp of each packet sent:
$ sudo fping -D -l -p 20 google.com [1612995038.31063] google.com : [0], 64 bytes, 7.87 ms (7.87 avg, 0% loss) [1612995038.31905] google.com : [1], 64 bytes, 6.23 ms (7.05 avg, 0% loss) [1612995038.32906] google.com : [2], 64 bytes, 6.15 ms (6.75 avg, 0% loss) [1612995038.34371] google.com : [3], 64 bytes, 6.14 ms (6.60 avg, 0% loss) [1612995038.36380] google.com : [4], 64 bytes, 6.22 ms (6.52 avg, 0% loss) [1612995038.38376] google.com : [5], 64 bytes, 6.18 ms (6.47 avg, 0% loss) [1612995038.40372] google.com : [6], 64 bytes, 6.14 ms (6.42 avg, 0% loss) [1612995038.42370] google.com : [7], 64 bytes, 6.12 ms (6.38 avg, 0% loss) [1612995038.44356] google.com : [8], 64 bytes, 5.99 ms (6.34 avg, 0% loss) [1612995038.46358] google.com : [9], 64 bytes, 6.01 ms (6.31 avg, 0% loss) [1612995038.48356] google.com : [10], 64 bytes, 5.99 ms (6.28 avg, 0% loss) [1612995038.50345] google.com : [11], 64 bytes, 5.87 ms (6.24 avg, 0% loss) [1612995038.52351] google.com : [12], 64 bytes, 5.94 ms (6.22 avg, 0% loss) [1612995038.55759] google.com : [13], timed out (6.22 avg, 7% loss) [1612995038.57774] google.com : [14], timed out (6.22 avg, 13% loss) [1612995038.59770] google.com : [15], timed out (6.22 avg, 18% loss) [1612995038.61764] google.com : [16], timed out (6.22 avg, 23% loss) . . . [1612995044.81775] google.com : [326], timed out (6.22 avg, 96% loss) [1612995044.83762] google.com : [327], timed out (6.22 avg, 96% loss) [1612995044.85775] google.com : [328], timed out (6.22 avg, 96% loss) [1612995044.87762] google.com : [329], timed out (6.22 avg, 96% loss) ^C google.com : xmt/rcv/%loss = 330/13/96%, min/avg/max = 5.87/6.22/7.87
In this example, I am pinging google.com with a period of 20 milliseconds. The interesting observation is that the first ten or so packets get a response, and after that google.com stops responding. My assumption is that if Google detects such a low pinging period, it rate limits the responses to avoid DDoS attacks. If you try the same ping with a local host in your network, you won’t see this behavior. Keep in mind that when you use the -p flag the timeout time is less or equal to the period (e.g. if you sed a period of 1 millisecond and the host doesn’t respond within 1 millisecond, then that ping test will be considered as a failed one).
Host Scanning
For me, one of the most useful features of fping is the quick host discovery within a subnet or within an IP range with the generate-list option -g. Here is an example.
$ sudo fping -g 172.31.0.0/24 172.31.0.1 is alive 172.31.0.14 is alive 172.31.0.16 is alive 172.31.0.17 is alive 172.31.0.18 is alive 172.31.0.21 is alive 172.31.0.25 is alive 172.31.0.38 is alive 172.31.0.39 is alive ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3 . . . ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.252 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254 ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254 172.31.0.2 is unreachable 172.31.0.3 is unreachable 172.31.0.4 is unreachable 172.31.0.5 is unreachable 172.31.0.6 is unreachable 172.31.0.7 is unreachable 172.31.0.8 is unreachable 172.31.0.9 is unreachable . . . 172.31.0.250 is unreachable 172.31.0.251 is unreachable 172.31.0.252 is unreachable 172.31.0.253 is unreachable 172.31.0.254 is unreachable
I find this output to be too verbose. Usually, I am interested in discovering all pingable hosts in a subnet, and here is how I do it.
$ sudo fping -q -a -s -g 172.31.0.0/24
172.31.0.1
172.31.0.14
172.31.0.16
172.31.0.17
172.31.0.18
172.31.0.21
172.31.0.25
172.31.0.38
172.31.0.39
172.31.0.183
172.31.0.188
172.31.0.222
172.31.0.223
172.31.0.243
254 targets
14 alive
240 unreachable
0 unknown addresses
960 timeouts (waiting for response)
974 ICMP Echos sent
14 ICMP Echo Replies received
960 other ICMP received
0.043 ms (min round trip time)
0.399 ms (avg round trip time)
0.906 ms (max round trip time)
9.697 sec (elapsed real time)
This uses the quiet flag-q, only targets that are alive with -a, and also prints a summary of statistics at the end with-s.
Additionally, fping can take as input a file that has a list of target hosts. As an example, I have the following file
$ cat ping-hosts.txt google.com one.one.one.one cnn.com cmu.edu
And I can ask fping to ping all these hosts to check if they are alive with:
$ sudo fping -f ping-hosts.txt [sudo] password for panos: google.com is alive one.one.one.one is alive cnn.com is alive cmu.edu is alive
Or I can run continuous ping tests with:
$ sudo fping -l -f ping-hosts.txt google.com : [0], 64 bytes, 6.89 ms (6.89 avg, 0% loss) one.one.one.one : [0], 64 bytes, 7.11 ms (7.11 avg, 0% loss) cnn.com : [0], 64 bytes, 9.20 ms (9.20 avg, 0% loss) cmu.edu : [0], 64 bytes, 62.8 ms (62.8 avg, 0% loss) google.com : [1], 64 bytes, 6.81 ms (6.85 avg, 0% loss) one.one.one.one : [1], 64 bytes, 6.51 ms (6.81 avg, 0% loss) cnn.com : [1], 64 bytes, 8.47 ms (8.84 avg, 0% loss) cmu.edu : [1], 64 bytes, 62.2 ms (62.5 avg, 0% loss) google.com : [2], 64 bytes, 7.88 ms (7.19 avg, 0% loss) one.one.one.one : [2], 64 bytes, 7.25 ms (6.96 avg, 0% loss) cnn.com : [2], 64 bytes, 9.09 ms (8.92 avg, 0% loss) cmu.edu : [2], 64 bytes, 62.5 ms (62.5 avg, 0% loss) google.com : [3], 64 bytes, 6.74 ms (7.08 avg, 0% loss) one.one.one.one : [3], 64 bytes, 6.35 ms (6.80 avg, 0% loss) cnn.com : [3], 64 bytes, 8.85 ms (8.90 avg, 0% loss) cmu.edu : [3], 64 bytes, 62.6 ms (62.5 avg, 0% loss) google.com : xmt/rcv/%loss = 4/4/0%, min/avg/max = 6.74/7.08/7.88 one.one.one.one : xmt/rcv/%loss = 4/4/0%, min/avg/max = 6.35/6.80/7.25 cnn.com : xmt/rcv/%loss = 4/4/0%, min/avg/max = 8.47/8.90/9.20 cmu.edu : xmt/rcv/%loss = 4/4/0%, min/avg/max = 62.2/62.5/62.8
Note that when fping sends ICMP requests to multiple hosts, it does that in parallel without waiting for one host to respond and then move to the next one.
Fping has several other options, but not too many to be overwhelming. They are available underfping --help.
