fping6 -g surely does not make sense in SLAAC environments or with other larger ranges at the size of /64.

But for DHCPv6 managed IPv6 ranges (like the /115 and /118 ranges we use at ETH) there is likely some use.

I have no idea where to make the cut for refusing or at least warning the user about pinging a too big range.

Initially reported at http://bugs.debian.org/558651by Matt LaPlante [email protected]:

The -A flag in fping is used to "show targets by address". fping6 also offers this flag according to usage(), but it doesn't work:

root@prizm:~# host www.kame.net
www.kame.net has address 203.178.141.194
www.kame.net has IPv6 address 2001:200:0:8002:203:47ff:fea5:3085
root@prizm:~# fping -A www.kame.net
203.178.141.194 is alive
root@prizm:~# fping6 -A www.kame.net
www.kame.net is alive

It should say "2001:200:0:8002:203:47ff:fea5:3085 is alive".

I could reproduce this issue with 3.1rc1

Solaris 8 needs a patch to compile

fping 3.7 does a segmentation fault when running in loop mode. Reported by Vlad Glagolev

If fping is started with "-c 20", and duplicate replies are detected, the duplicates are apparently making the total count decrease, so that fping stops early and doesn't send 20 echo request packets.

(reported by Ramon Schwammberger)

FreeBSD is using the 3.4 port instead of the old 2.4 'patched' version.

Since upgrading my fping port to 3.4, fping is causing a lot of errors in my scripts.
After some checks, I've found it sometimes (not always) gives strange results.

./fping -b 1400 < /Monitoring/temp/recheck.txt

10.202.55.129 is unreachable
10.202.16.65 is unreachable
10.202.37.1 is unreachable
10.200.0.25 is unreachable
10.200.0.26 is unreachable
10.200.0.27 is unreachable
10.202.135.191 is unreachable

./fping -b 1400 < /Monitoring/temp/recheck.txt

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

10.200.0.25 error while sending ping: Host is down

10.200.0.26 error while sending ping: Host is down

10.200.0.27 error while sending ping: Host is down

It only seems the happen with the 10.200.0/24 ip addresses.
The host itself is also in the 10.200.0/24 subnet.

Wen I run the same command with the fold 2.4 fping, it's fine.

I am not sure that this is possible, but it would be useful to be able to specify a "outgoing interface". This would work similarly to the '-I' option, but would only affect the "ICMP ECHO REQUEST" packets and would allow for the "REPLY" to be coming from a different interface.

This patch prints the received TOS field in verbose mode:

--- fping-3.4/src/fping.c       2012-09-04 09:27:51.000000000 +0200
+++ fping-3.4/src/fping.c_new   2013-01-25 11:10:01.512709641 +0100
@@ -243,6 +243,7 @@
      int                  min_reply_i;        /* shortest response time */
      int                  total_time_i;       /* sum of response times */
      int                  *resp_times;        /* individual response times */
+     int                  tos;
 #if defined( DEBUG ) || defined( _DEBUG )
      int                  *sent_times;        /* per-sent-ping timestamp */
 #endif /* DEBUG || _DEBUG */
@@ -1750,6 +1751,7 @@
     sum_replies += this_reply;
     h->total_time += this_reply;
     h->total_time_i += this_reply;
+    h->tos = ip->ip_tos;
     total_replies++;

     /* note reply time in array, probably */
@@ -1800,7 +1802,7 @@
             printf( "%s", h->host );

             if( verbose_flag )
-                printf( " is alive" );
+                printf( " is alive (TOS %d)", h->tos );

             if( elapsed_flag )
                 printf( " (%s ms)", sprint_tm( this_reply ) );

I have found a bug when compiling and running fping6 on solaris 11. I should note that I work as the root user on my solaris box so should not be a permissions issue. No matter what options were provided to fping6, it always returned the following setsockopt error:

~/fping-3.4/src# ./fping6 -v
fping6: setsockopt(SOL_RAW,IPV6_CHECKSUM): Invalid argument

Testing on my Ubuntu 12.04 machine the code performs as expected, the issues only occurred for me on solaris.Upon investigation I have found that the IPV6_CHECKSUM is invalid for ICMPv6 RAW sockets as explained Here.

From this I have found that disabling the code in fping.c from line 474 to line 476 (as shown below) appears to fix the issue.

opton = 2;
//if (setsockopt(s, SOL_RAW, IPV6_CHECKSUM, &opton,
// sizeof(opton)))
// err(1, "setsockopt(SOL_RAW,IPV6_CHECKSUM)");


After a recompile the same command now produces the expected output

:~/fping/src# ./fping6 -v
./fping6: Version 3.4
./fping6: comments to [email protected]

Testing some IPv6 addresses also seems to work as expected

:/fping/src# ./fping6 fe80::baac:6fff:fe7d:e933
fe80::baac:6fff:fe7d:e933 is alive
:/fping/src# ./fping6 fe80::baac:6fff:fe7d:e934
fe80::baac:6fff:fe7d:e934 is unreachable

:/fping/src# ./fping6 2aab::baac:6fff:fe7d:e933
2aab::baac:6fff:fe7d:e933 is alive
:/fping/src# ./fping6 2aab::baac:6fff:fe7d:e934
2aab::baac:6fff:fe7d:e934 is unreachable

The modified code also continues to perform as expected on Ubuntu so I can only assume that Linux must simply ignore the setsockopt code and carry on without producing an error. Can someone replicate this and confirm that this modification does fix the issue?

after 65536 ping requests in a loop the responses are misinterpreted:
(here 10922*6 + 4 = 65536 -> unsigned char var ?)

192.168.0.50 (192.168.0.50) : [10921], 84 bytes, 1.20 ms (1.86 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10921], 84 bytes, 1.24 ms (1.97 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10921], 84 bytes, 1.16 ms (2.00 avg, 0% loss)
192.168.0.46 (192.168.0.46) : [10921], 84 bytes, 0.66 ms (1.81 avg, 0% loss)
192.168.0.46 (192.168.0.46) : [10921], 84 bytes, 0.59 ms (1.79 avg, 0% loss)
192.168.0.46 (192.168.0.46) : [10921], 84 bytes, 0.68 ms (1.83 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10922], 84 bytes, 1.31 ms (1.86 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10922], 84 bytes, 1.13 ms (1.97 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10922], 84 bytes, 1.27 ms (2.00 avg, 0% loss)
192.168.0.46 (192.168.0.46) : [10922], 84 bytes, 0.62 ms (1.81 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10922], 84 bytes, 0.61 ms (1.86 avg, 100% return) [<- 192.168.0.46]
192.168.0.50 (192.168.0.50) : [10922], 84 bytes, 0.61 ms (1.97 avg, 100% return) [<- 192.168.0.46]
192.168.0.50 (192.168.0.50) : [10923], 84 bytes, 1.29 ms (2.00 avg, 100% return)
192.168.0.46 (192.168.0.46) : [10923], 84 bytes, 1.34 ms (1.81 avg, 100% return) [<- 192.168.0.50]
192.168.0.46 (192.168.0.46) : [10923], 84 bytes, 1.26 ms (1.79 avg, 0% loss) [<- 192.168.0.50]
192.168.0.46 (192.168.0.46) : [10923], 84 bytes, 0.60 ms (1.83 avg, 0% loss)
192.168.0.50 (192.168.0.50) : [10923], 84 bytes, 0.55 ms (1.86 avg, 100% return) [<- 192.168.0.46]
192.168.0.50 (192.168.0.50) : [10923], 84 bytes, 0.59 ms (1.97 avg, 100% return) [<- 192.168.0.46]

Hi David,

while fping 3.6 builds fine on Debian Unstable, fping 3.7 fails to build:

Making all in src
make[4]: Entering directory `/home/abe/fping/fping/build/ipv6/src'
gcc -DHAVE_CONFIG_H -I. -I../../src -I..   -DIPV6=1 -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -MT fping.o -MD -MP -MF .deps/fping.Tpo -c -o fping.o ../../src/fping.c
../../src/fping.c: In function ‘main’:
../../src/fping.c:371:16: warning: ignoring return value of ‘seteuid’, declared with attribute warn_unused_result [-Wunused-result]
         seteuid( getuid() );
                ^
mv -f .deps/fping.Tpo .deps/fping.Po
gcc -DHAVE_CONFIG_H -I. -I../../src -I..   -DIPV6=1 -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -MT seqmap.o -MD -MP -MF .deps/seqmap.Tpo -c -o seqmap.o ../../src/seqmap.c
mv -f .deps/seqmap.Tpo .deps/seqmap.Po
gcc -DHAVE_CONFIG_H -I. -I../../src -I..   -DIPV6=1 -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -MT socket.o -MD -MP -MF .deps/socket.Tpo -c -o socket.o ../../src/socket.c
mv -f .deps/socket.Tpo .deps/socket.Po
gcc -DHAVE_CONFIG_H -I. -I../../src -I..   -DIPV6=1 -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -MT socket4.o -MD -MP -MF .deps/socket4.Tpo -c -o socket4.o ../../src/socket4.c
../../src/socket4.c: In function ‘socket_set_src_addr_ipv4’:
../../src/socket4.c:69:17: error: incompatible types when assigning to type ‘struct in_addr’ from type ‘struct in6_addr’
     sa.sin_addr = src_addr;
                 ^
make[4]: *** [socket4.o] Error 1
make[4]: Leaving directory `/home/abe/fping/fping/build/ipv6/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/abe/fping/fping/build/ipv6'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/abe/fping/fping/build/ipv6'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/home/abe/fping/fping'
make: *** [build] Error 2

Is there a easy guide to compile fping using mingw?

I'm still trying to isolate a reproducible case, as this is being sent directly from our monitoring system (which varies with each run), but the following crash occurred on a heavily loaded RHEL6 system.

*** buffer overflow detected ***: /usr/sbin/fping terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f17cd7d7d47]
/lib64/libc.so.6(+0xffc30)[0x7f17cd7d5c30]
/lib64/libc.so.6(+0xff089)[0x7f17cd7d5089]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7f17cd74a0e9]
/lib64/libc.so.6(_IO_vfprintf+0x101a)[0x7f17cd71b27a]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f17cd7d512d]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x7f17cd7d506f]
/usr/sbin/fping[0x401a95]
/usr/sbin/fping[0x4034dd]
/usr/sbin/fping[0x4035d7]
/usr/sbin/fping[0x40450e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f17cd6f4cdd]
/usr/sbin/fping[0x401379]
======= Memory map: ========
00400000-00407000 r-xp 00000000 fd:00 1971659 /usr/sbin/fping
00606000-00607000 rw-p 00006000 fd:00 1971659 /usr/sbin/fping
00607000-00608000 rw-p 00000000 00:00 0
014a6000-014c7000 rw-p 00000000 00:00 0 [heap]
7f17cd2b2000-7f17cd2c8000 r-xp 00000000 fd:00 1292474 /lib64/libgcc_s-4.4.6-20120305.so.1
7f17cd2c8000-7f17cd4c7000 ---p 00016000 fd:00 1292474 /lib64/libgcc_s-4.4.6-20120305.so.1
7f17cd4c7000-7f17cd4c8000 rw-p 00015000 fd:00 1292474 /lib64/libgcc_s-4.4.6-20120305.so.1
7f17cd4c8000-7f17cd4d4000 r-xp 00000000 fd:00 2883613 /lib64/libnss_files-2.12.so
7f17cd4d4000-7f17cd6d4000 ---p 0000c000 fd:00 2883613 /lib64/libnss_files-2.12.so
7f17cd6d4000-7f17cd6d5000 r--p 0000c000 fd:00 2883613 /lib64/libnss_files-2.12.so
7f17cd6d5000-7f17cd6d6000 rw-p 0000d000 fd:00 2883613 /lib64/libnss_files-2.12.so
7f17cd6d6000-7f17cd85f000 r-xp 00000000 fd:00 2883597 /lib64/libc-2.12.so
7f17cd85f000-7f17cda5f000 ---p 00189000 fd:00 2883597 /lib64/libc-2.12.so
7f17cda5f000-7f17cda63000 r--p 00189000 fd:00 2883597 /lib64/libc-2.12.so
7f17cda63000-7f17cda64000 rw-p 0018d000 fd:00 2883597 /lib64/libc-2.12.so
7f17cda64000-7f17cda69000 rw-p 00000000 00:00 0
7f17cda69000-7f17cda89000 r-xp 00000000 fd:00 2883587 /lib64/ld-2.12.so
7f17cdc76000-7f17cdc79000 rw-p 00000000 00:00 0
7f17cdc85000-7f17cdc88000 rw-p 00000000 00:00 0
7f17cdc88000-7f17cdc89000 r--p 0001f000 fd:00 2883587 /lib64/ld-2.12.so
7f17cdc89000-7f17cdc8a000 rw-p 00020000 fd:00 2883587 /lib64/ld-2.12.so
7f17cdc8a000-7f17cdc8b000 rw-p 00000000 00:00 0
7fffb24de000-7fffb24f4000 rw-p 00000000 00:00 0 [stack]
7fffb25ff000-7fffb2600000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted

Compiled with: gcc -DHAVE_CONFIG_H -I. -I.. -DENABLE_F_OPTION -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT fping.o -MD -MP -MF .deps/fping.Tpo -c -o fping.o fping.c

reported by Alexander Ivanov on 22 August 2013:

Hello David!

Sorry, I can't report this issue at github.com (unable to find
https://github.com/schweikert/fping/issues/new), so I'm writing email to
you.

Look at "min" rtt values, -Q option reports wrong minimum time (0.00).

# src/fping -c 25 -Q 5 8.8.8.8
[16:21:52]
8.8.8.8 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/37.5/37.6
[16:21:57]
8.8.8.8 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/37.6/37.6
[16:22:02]
8.8.8.8 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/37.5/37.7
[16:22:07]
8.8.8.8 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/37.6/37.6
8.8.8.8 : xmt/rcv/%loss = 25/25/0%, min/avg/max = 37.5/37.5/37.7

# src/fping -v
src/fping: Version 3.5
src/fping: comments to [email protected]

Thank you!

With best regards, Alexander

Initially reported at http://bugs.debian.org/661195 by Heiko Schlittermann [email protected]:

According to the man page, "-q" should suppress the output. It seems to work if not combined with "-c", but if I use "-c" the result looks as follows:

$ fping -c1 -q 8.8.8.8
8.8.8.8 : xmt/rcv/%loss = 0/0/0%

I could reproduce this issue with 3.1rc1

Support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. fping appears to use an earlier version of autoconf, preventing its being built on aarch64. Can you please update to autoconf 2.69?

Please see https://bugzilla.redhat.com/show_bug.cgi?id=925355 for more details.

Thanks.

It would be nice to have this in fping as well:

http://anarcat.koumbit.org/2013-12-03-announcing-prettier-noping
octo/liboping#3

help output goes to stderr - it should go to stdout instead

Tested on fping 3.3.

The usage output says:

fping: these options are too risky for mere mortals.
fping: You need i >= 10, p >= 20, r < 20, and t >= 50

The manual page says differently (and is missing the restriction on the -p option):

RESTRICTIONS
If certain options are used (i.e, a low value for -i and -t, and a high
value for -r) it is possible to flood the network. This program must be
installed as setuid root in order to open up a raw socket, or must be
run by root. In order to stop mere mortals from hosing the network,
normal users can't specify the following:

   ·   -i n, where n < 10 msec

   ·   -r n, where n > 20

   ·   -t n, where n < 250 msec

The actual behavior that non-root is allowed to do is different from both of the above documentations (Usage message is mostly correct, only -r has a < instead of the more correct <=):

-i >= 10
-p >= 20
-r <= 20
-t >= 50

Finally, the usage message "default" values change to show what you gave on the command line when specifying out-of-range values for non-root users. E.g. if as non-root you specify -i9 you see:

fping: You need i >= 10, p >= 20, r < 20, and t >= 50

Usage: fping [options] [targets...]
[...]
-i n interval between sending ping packets (in millisec) (default 9) <----- the default changed here to the actual value given

The same is true for -i, -p, and -t. The -r option default value always displays correctly.

If running fping using the -q option to only return exit status on a "down" host in the same subnet, the system outputs on STDERR "ICMP Host Unreachable ....".

While there are ways to programmatically get around this, is it possible for fping to deal with this output when using the -q option? I would expect this as the standard behavior.

This behavior exists in the legacy and current versions fping <= version 3

Ex.:
/usr/local/sbin/fping -q 192.168.1.10
ICMP Host Unreachable from 192.168.1.5 for ICMP Echo sent to 192.168.1.10

This is on STDERR as redirecting STDERR removes the messages.
Ex.
/usr/local/sbin/fping -q 192.168.1.10 2> /dev/null

Thanks!

i'm using smokeping, after running for a while fping does not exit, it's taking full cpu resource (1 core)
command line of fping is:
/usr/sbin/fping -C 20 -q -B1 -r1 -i10 192.168.3.14 192.168.3.11 192.168.17.1 192.168.8.1 192.168.3.12 192.168.31.1 192.168.1.2

after some minutes digging i see weird thing:
(gdb) p ev_first.ev_next
$3 = (struct host_entry *) 0x7f1124aeed80
(gdb) p ev_first.ev_next.ev_next
$4 = (struct host_entry *) 0x7f1124aeed80
(gdb) p ev_first.ev_next.ev_next.ev_next
$5 = (struct host_entry *) 0x7f1124aeed80

(gdb) while $p.ev_prev

p $p
set $p = $p.ev_prev
end
$15 = (struct host_entry *) 0x7f1124af0080
$16 = (struct host_entry *) 0x7f1124aefd80
$17 = (struct host_entry *) 0x7f1124aefb80
$18 = (struct host_entry *) 0x7f1124aef980
$19 = (struct host_entry *) 0x7f1124aef880
$20 = (struct host_entry *) 0x7f1124aef780
$21 = (struct host_entry *) 0x7f1124aef680
$22 = (struct host_entry *) 0x7f1124aef280
$23 = (struct host_entry *) 0x7f1124aef080
$24 = (struct host_entry *) 0x7f1124aeef80
$25 = (struct host_entry *) 0x7f1124aeed80
$26 = (struct host_entry *) 0x7f1124aeed80

looks like 0x7f1124aeed80 is looping to itself

there is a lot of trailing whitespace in the code. as part of the cleanup, it could be nuked with the attached patch :)

It takes 20 minutes to ping 20000 machines, and %90 of the time is spent on gethostbyname() in add_name().
Is it possible to replace gethostbyname/getaddrinfo with non-block call getaddrinfo_a?

fping crashes while reporting when it receieves more packets than expected

this hints

a) that something fundamental with the sockets might have changed recently
b) calculation and error handling near the output is susceptable to errors

------------ example output -------------
[jens@monitor-1 ~]$ /usr/sbin/fping -l -Q 60 134.130.3.126
[09:08:25]
134.130.3.126 : xmt/rcv/%loss = 60/60/0%, min/avg/max = 0.00/0.60/1.32
[09:09:25]
134.130.3.126 : xmt/rcv/%loss = 60/60/0%, min/avg/max = 0.00/0.67/7.45

[...]

[09:39:25]
134.130.3.126 : xmt/rcv/%loss = 60/60/0%, min/avg/max = 0.00/0.53/0.77
[09:40:26]
134.130.3.126 : xmt/rcv/%return = 60/63/105%, min/avg/max = 0.00*** buffer overflow detected ***: /usr/sbin/fping terminated
======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x36914e8ccf]
/lib64/libc.so.6[0x36914e8139]
/lib64/libc.so.6(_IO_default_xsputn+0x94)[0x369146d5a4]
/lib64/libc.so.6(_IO_vfprintf+0xe7a)[0x36914439da]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x36914e81dd]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x36914e8120]
/usr/sbin/fping[0x401b70]
/usr/sbin/fping[0x40347f]
/usr/sbin/fping[0x40359e]
/usr/sbin/fping[0x403f4e]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x369141d9c4]
/usr/sbin/fping[0x401429]
======= Memory map: ========
00400000-00407000 r-xp 00000000 fd:00 19766302 /usr/sbin/fping
00606000-00607000 rw-p 00006000 fd:00 19766302 /usr/sbin/fping
00607000-00608000 rw-p 00607000 00:00 0
00806000-00807000 rw-p 00006000 fd:00 19766302 /usr/sbin/fping
0e66b000-0e68c000 rw-p 0e66b000 00:00 0 [heap]
3691000000-369101c000 r-xp 00000000 fd:00 1343548 /lib64/ld-2.5.so
369121c000-369121d000 r--p 0001c000 fd:00 1343548 /lib64/ld-2.5.so
369121d000-369121e000 rw-p 0001d000 fd:00 1343548 /lib64/ld-2.5.so
3691400000-369154f000 r-xp 00000000 fd:00 1343667 /lib64/libc-2.5.so
369154f000-369174f000 ---p 0014f000 fd:00 1343667 /lib64/libc-2.5.so
369174f000-3691753000 r--p 0014f000 fd:00 1343667 /lib64/libc-2.5.so
3691753000-3691754000 rw-p 00153000 fd:00 1343667 /lib64/libc-2.5.so
3691754000-3691759000 rw-p 3691754000 00:00 0
3696800000-369680d000 r-xp 00000000 fd:00 1343691 /lib64/libgcc_s-4.1.2-20080825.so.1
369680d000-3696a0d000 ---p 0000d000 fd:00 1343691 /lib64/libgcc_s-4.1.2-20080825.so.1
3696a0d000-3696a0e000 rw-p 0000d000 fd:00 1343691 /lib64/libgcc_s-4.1.2-20080825.so.1
2b53db8fb000-2b53db8fd000 rw-p 2b53db8fb000 00:00 0
2b53db90c000-2b53db90d000 rw-p 2b53db90c000 00:00 0
2b53db90d000-2b53db917000 r-xp 00000000 fd:00 1343664 /lib64/libnss_files-2.5.so
2b53db917000-2b53dbb16000 ---p 0000a000 fd:00 1343664 /lib64/libnss_files-2.5.so
2b53dbb16000-2b53dbb17000 r--p 00009000 fd:00 1343664 /lib64/libnss_files-2.5.so
2b53dbb17000-2b53dbb18000 rw-p 0000a000 fd:00 1343664 /lib64/libnss_files-2.5.so
7fffbde4a000-7fffbde5f000 rw-p 7ffffffe9000 00:00 0 [stack]
7fffbdffd000-7fffbe000000 r-xp 7fffbdffd000 00:00 0 [vdso]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vsyscall]

The code should be made more modern and use sockaddr_storage for unified storage of ipv4 and ipv6 addresses.

At Zabbix, we have noticed that when trying to ping a broadcast address fping sometimes outputs a random value. For instance (slightly reformatted):

$ sudo ./fping -C3 192.168.1.255
192.168.1.255 : 10743047.12 - -

$ sudo ./fping -C3 192.168.1.255
192.168.1.255 : - - -

$ sudo ./fping -C3 192.168.1.255
192.168.1.255 : 19207226.32 - -

$ sudo ./fping -C3 192.168.1.255
192.168.1.255 : 3566691.28 - -

$ sudo ./fping -C3 192.168.1.255
192.168.1.255 : 11251074.00 - -

Upon further investigation we noticed that when pinging a broadcast address sendto() in function send_ping() fails with the following error:

$ sudo ./fping 192.168.1.255
192.168.1.255 error while sending ping: Permission denied
....

At this point, we find it strange that in the latest version of fping function send_ping() always succeeds by returning 1 (unlike version 3.2, for instance). The only difference between the case when sendto() fails and when sendto() succeeds is the setting of h->resp_times[h->num_sent] to RESP_WAITING in the latter case. We find this suspicious and wish to draw your attention to it, but it might as well be OK.

Anyway, we have fixed the problem by applying the following patch which adds initialization of the first element of resp_times array and would like to ask you to review:

$ git diff
diff --git a/src/fping.c b/src/fping.c
index 8316cc3..6a89f0f 100644
--- a/src/fping.c
+++ b/src/fping.c
@@ -2209,7 +2209,7 @@ void add_addr( char *name, char *host, FPING_SOCKADDR *ipaddr )
         if( !i )
             crash_and_burn( "can't allocate resp_times array" );

-        for( n = 1; n < trials; n++ )
+        for( n = 0; n < trials; n++ )
             i[n] = RESP_UNUSED;

         p->resp_times = i;
@@ -2224,7 +2224,7 @@ void add_addr( char *name, char *host, FPING_SOCKADDR *ipaddr )
         if( !i )
             crash_and_burn( "can't allocate sent_times array" );

-        for( n = 1; n < trials; n++ )
+        for( n = 0; n < trials; n++ )
             i[n] = RESP_UNUSED;

         p->sent_times = i;

Please see https://support.zabbix.com/browse/ZBX-7576 for details on why it mattered for us.

Initially reported at http://bugs.debian.org/308695 by Norbert Buchmuller [email protected]:

The meant-to-be infinite loop with '-l' breaks when the route on the local system to the target host disappears. This is surely not the desired behaviour, since it breaks the loop that is assumed to be infinite; moreover, it differentiates between the facts that the route to the target is broken on the local host, or somewhere further.

Here's what happens if I delete the default route approx. 6 seconds after I start fping:

mendel@vger:~$ fping -l 217.65.111.222
217.65.111.222 : [0], 84 bytes, 21.4 ms (21.4 avg, 0% loss)
217.65.111.222 : [1], 84 bytes, 21.2 ms (21.3 avg, 0% loss)
217.65.111.222 : [2], 84 bytes, 21.9 ms (21.5 avg, 0% loss)
217.65.111.222 : [3], 84 bytes, 25.3 ms (22.5 avg, 0% loss)
217.65.111.222 : [4], 84 bytes, 23.2 ms (22.6 avg, 0% loss)
217.65.111.222 : [5], 84 bytes, 38.6 ms (25.3 avg, 0% loss)
217.65.111.222 : [6], 84 bytes, 45.7 ms (28.2 avg, 0% loss)

217.65.111.222 : xmt/rcv/%loss = 7/7/0%, min/avg/max = 21.2/28.2/45.7
mendel@vger:~$ 

If I start fping when there's no default route:

mendel@vger:~$ fping -l 217.65.111.222

217.65.111.222 : xmt/rcv/%loss = 0/0/0%
mendel@vger:~$ 

I could reproduce this issue with 3.1rc1.

Initially reported at http://bugs.debian.org/558652 and https://bugs.launchpad.net/ubuntu/+source/fping/+bug/489860 by Matt LaPlante [email protected]:

fping behaves badly when options inet6 is configured in the resolver. It appears that the code calls gethostbyname() without checking the address family of the result. When the resolver returns an AF_INET6 address, it treats it as IPv4, grabs only part of the address, and attempts the ping. The ping fails, but without an error indicating why. Running with -A shows that a nonsensical IPv4 address is being pinged instead of the expected address. This obviously only affects hosts which have an AAAA address in dns.

root@prizm:~# host www.kame.net
www.kame.net has address 203.178.141.194
www.kame.net has IPv6 address 2001:200:0:8002:203:47ff:fea5:3085

options inet6 off:

root@prizm:~# fping6 -A www.kame.net
www.kame.net is alive
root@prizm:~# fping -A www.kame.net
203.178.141.194 is alive

options inet6 on:

root@prizm:~# fping6 -A www.kame.net
www.kame.net is alive
root@prizm:~# fping -A www.kame.net
32.1.2.0 is unreachable

fping6 don't show host name, when problems with DNS resolving:

[pavlicek@fisadm ~]$ fping6 -e www.google.com ipv6.google.com ipv4.google.com notexist.google.com
fping6: No address associated with hostname
fping6: Name or service not known
www.google.com is alive (43.9 ms)
ipv6.google.com is alive (14.7 ms)

fping (IPv4) host names are printed:

[pavlicek@fisadm ~]$ fping -e www.google.com ipv6.google.com ipv4.google.com notexist.google.com
ipv6.google.com address not found
notexist.google.com address not found
www.google.com is alive (3.26 ms)
ipv4.google.com is alive (2.93 ms)

Tested with 3.3-rc1 version of fping.

Possible to add a feature for logging result ?

If I got it correctly - in "none default" mode ("batch mode" next) fping will receive and will process ECHO replies for previous requests as success till it executes last request disregarding that replies have been received much later that specified in -t option.

For example ping to a site with long distance.

# time ./fping -c1 -t50 zabbix.jp

zabbix.jp : xmt/rcv/%loss = 1/0/100%

real    0m0.078s
user    0m0.000s
sys 0m0.000s

# time ./fping -c2 -t50 zabbix.jp
zabbix.jp : [0], 84 bytes, 175 ms (175 avg, 0% loss)

zabbix.jp : xmt/rcv/%loss = 2/1/50%, min/avg/max = 175/175/175

real    0m1.079s
user    0m0.000s
sys 0m0.000s


# time ./fping -c5 -t50 zabbix.jp
zabbix.jp : [0], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [1], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [2], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [3], 84 bytes, 174 ms (174 avg, 0% loss)

zabbix.jp : xmt/rcv/%loss = 5/4/20%, min/avg/max = 174/174/174

real    0m4.082s
user    0m0.000s
sys 0m0.000s

As we see above one last response always lost because fping finished its work before last response came.

And with none default -p option, so two last responses are lost while first response has been catched:

# time ./fping -c3 -t50 -p50 zabbix.jp
zabbix.jp : [0], 84 bytes, 174 ms (174 avg, 66% loss)

zabbix.jp : xmt/rcv/%loss = 3/1/66%, min/avg/max = 174/174/174

real    0m0.178s
user    0m0.000s
sys 0m0.000s

I'd consider this as a fping's bug because it's nasty inconsistency which depends on number of requests sent and it's absolutely not clear.

I believe that timeouts in none default "batch" mode should work as expected disregarding on number of requests.
So in all my examples I should get 100% lost responses.

Hi upstream,

We downstream fping package maintainer has recieved a bug report of fping yesterday, can you help us?

Thanks.

Bugzilla URL: https://bugzilla.redhat.com/show_bug.cgi?id=989200

Hello, Homebrew is a software installer for OSX, and I'm upgrading the formula for fping to use your version. By design, Homebrew does not install anything with sudo, simply by changing the ownership of /usr/local to the user who installs everything. Is there a patch so that fping can be run without changing the owner to root and without chown u+s? I would have tried to craft one for you, but I'm unfamiliar with this. Thanks.

I know this is minor and the example more or less stupid:

$ fping -a -g 2001:db8:120:4161::4/64
Error: netmask must be between 1 and 30 (is: 64)
$ fping -a -g 2001:db8:120:4161::4/30
Error: -g works only with IPv4 addresses

But I think that in fping6 the -g check should come before the (IPv4!) netmask check, i.e. that the above example throws the "-g works only with IPv4 addresses" already in the first case, not only in the second.

Initially reported at http://bugs.debian.org/340297 by Marc Haber [email protected]:

fping prints "ICMP Host Unreachable from $GATEWAY for ICMP Echo sent to $ADDRESS". This is not even turned off by -q or -Q and clutters up the output. Please make selecting this output optional.

The "ICMP Host Unreachable from $GATEWAY for ICMP Echo sent to $ADDRESS" currently comes on STDERR and is hence easy to filter out, but it's nevertheless annoying.

I could reproduce this issue with 3.2rc1.

Hi.

Sending echo request to thousands of nodes by fping, sometimes I can find the RTT value exceeding the -w timeout setting.

I see, this is occured under the following two conditions,
a) actual RTT between sender and target node exceeds -w timeout value
and
b) sender has received echo reply from target node before fping process has been finished.

For example, pinging ageinst 3,000 nodes including one actual RTT=5000ms node (at the head of nodelist) with the options,

fping -r 0 -i 1 -c 1 -t 3000 -s -f <3,000 nodelist>

and fping reports the following summary.

3000 targets
   1 alive
2999 unreachable
   0 unknown addresses

3000 timeouts (waiting for response)
3000 ICMP Echos sent
   1 ICMP Echo Replies received
   0 other ICMP received

5000 ms (min round trip time)
5000 ms (avg round trip time)
5000 ms (max round trip time)
6.288 sec (elapsed real time)

Is this behavior expected or will be fixed?

Regards.

Call please somehow "none default" mode, for example as "batch" mode.
It will be easier to understand it and reference to it in description.

Start description of -B option as "Backoff factor. "+current description
Replace last sentence in description of -t option as: "Successive timeouts are multiplied by the backoff factor -B (only in default mode)"

Please describe cleanly in man DESCRIPTION that there is two modes ("default" and "batch") with corresponding noticeable headers.
Mention please that they accept/ignore different options.
Add there some line breaks to better readability.

Clarify in description of every option which being accepted/ignored in "default" and "batch" modes.

For example -B option is ignored for "batch" mode, discussed here:
https://lists.oetiker.ch/pipermail/smokeping-users/2005-November/001723.html

Also, in any case details from another just created issue #32 have to be described in man page as well.

fping should behave like iptools's ping for option -I: when an interface is given, then bind to that interface (as implemented already), if an IP address is given, then use that as source IP address.

The use case is that I want to do a ping sweep across the IP address range of a subnet, in order to count the machines that respond (and maybe populate the ARP cache so that I can count the ARP entries to count even live machines that do not respond to ICMP ECHO).

fping -q -s -g ... gets me this, but it can give lots of annoying messages for machines whose address cannot be resolved. These messages aren't interesting for this use case.

: leinen@momp2[fping]; ./src/fping -q -s -g 131.169.104.4/30
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.5
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.5
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.5
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.6
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.6
ICMP Host Unreachable from 131.169.105.99 for ICMP Echo sent to 131.169.104.6

   2 targets
   0 alive
   2 unreachable
   0 unknown addresses

   2 timeouts (waiting for response)
   8 ICMP Echos sent
   0 ICMP Echo Replies received
   6 other ICMP received

0.00 ms (min round trip time)
0.00 ms (avg round trip time)
0.00 ms (max round trip time)
4.116 sec (elapsed real time)

No problem, right? I can just redirect stderr to a safe place so that I don't see these warning messages. Unfortunately, the end results ("-s" statistics) are then also redirected:

: 1leinen@momp2[fping]; ./src/fping -q -s -g 131.169.104.4/30 2>/dev/null
: leinen@momp2[fping];

Obviously the statistics are sent to stderr. I hope that the above use case convinces you that this is wrong, and that they should be sent to stdout instead.

make all-recursive
make[1]: Entering directory /home/fping-3.5'
Making all in doc
make[2]: Entering directory/home/fping-3.5/doc'
make[2]: Nothing to be done for all'.
make[2]: Leaving directory/home/fping-3.5/doc'
Making all in src
make[2]: Entering directory /home/fping-3.5/src'
gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT fping.o -MD -MP -MF .deps/fping.Tpo -c -o fping.o fping.c
fping.c:103:14: warning: ‘optarg’ redeclared without dllimport attribute: previo us dllimport ignored [-Wattributes]
fping.c:104:12: warning: ‘optind’ redeclared without dllimport attribute: previo us dllimport ignored [-Wattributes]
fping.c:104:19: warning: ‘opterr’ redeclared without dllimport attribute: previo us dllimport ignored [-Wattributes]
fping.c:105:12: warning: ‘h_errno’ redeclared without dllimport attribute: previ ous dllimport ignored [-Wattributes]
fping.c:351:54: warning: ‘struct icmp’ declared inside parameter list [enabled b y default]
fping.c:351:54: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
fping.c: In function ‘main’:
fping.c:724:28: error: ‘ICMP_MINLEN’ undeclared (first use in this function)
fping.c:724:28: note: each undeclared identifier is reported only once for each function it appears in
fping.c: In function ‘send_ping’:
fping.c:1550:8: error: dereferencing pointer to incomplete type
fping.c:1550:22: error: ‘ICMP_ECHO’ undeclared (first use in this function)
fping.c:1551:8: error: dereferencing pointer to incomplete type
fping.c:1552:8: error: dereferencing pointer to incomplete type
fping.c:1553:8: error: dereferencing pointer to incomplete type
fping.c:1554:8: error: dereferencing pointer to incomplete type
fping.c:1556:36: error: ‘ICMP_MINLEN’ undeclared (first use in this function)
fping.c:1560:8: error: dereferencing pointer to incomplete type
fping.c: In function ‘wait_for_reply’:
fping.c:1679:25: error: ‘ICMP_MINLEN’ undeclared (first use in this function)
fping.c:1700:12: error: dereferencing pointer to incomplete type
fping.c:1700:27: error: ‘ICMP_ECHOREPLY’ undeclared (first use in this function)
fping.c:1706:9: warning: passing argument 1 of ‘handle_random_icmp’ from incompa tible pointer type [enabled by default]
fping.c:351:5: note: expected ‘struct icmp ’ but argument is of type ‘struct ic mp *’
fping.c:1712:9: error: dereferencing pointer to incomplete type
fping.c:1712:9: error: dereferencing pointer to incomplete type
fping.c:1712:9: error: dereferencing pointer to incomplete type
fping.c:1712:9: error: dereferencing pointer to incomplete type
fping.c:1721:9: error: dereferencing pointer to incomplete type
fping.c:1721:9: error: dereferencing pointer to incomplete type
fping.c:1721:9: error: dereferencing pointer to incomplete type
fping.c:1721:9: error: dereferencing pointer to incomplete type
fping.c:1728:9: error: dereferencing pointer to incomplete type
fping.c:1728:9: error: dereferencing pointer to incomplete type
fping.c:1728:9: error: dereferencing pointer to incomplete type
fping.c:1728:9: error: dereferencing pointer to incomplete type
fping.c:1742:28: error: dereferencing pointer to incomplete type
fping.c:1743:29: error: dereferencing pointer to incomplete type
fping.c: At top level:
fping.c:1901:54: warning: ‘struct icmp’ declared inside parameter list [enabled by default]
fping.c:1901:5: error: conflicting types for ‘handle_random_icmp’
fping.c:351:5: note: previous declaration of ‘handle_random_icmp’ was here
fping.c: In function ‘handle_random_icmp’:
fping.c:1913:14: error: dereferencing pointer to incomplete type
fping.c:1918:10: error: ‘ICMP_UNREACH’ undeclared (first use in this function)
fping.c:1924:24: error: dereferencing pointer to incomplete type
fping.c:1924:39: error: ‘ICMP_ECHO’ undeclared (first use in this function)
fping.c:1925:15: error: dereferencing pointer to incomplete type
fping.c:1925:15: error: dereferencing pointer to incomplete type
fping.c:1925:15: error: dereferencing pointer to incomplete type
fping.c:1925:15: error: dereferencing pointer to incomplete type
fping.c:1926:15: error: dereferencing pointer to incomplete type
fping.c:1926:15: error: dereferencing pointer to incomplete type
fping.c:1926:15: error: dereferencing pointer to incomplete type
fping.c:1926:15: error: dereferencing pointer to incomplete type
fping.c:1929:23: error: dereferencing pointer to incomplete type
fping.c:1929:23: error: dereferencing pointer to incomplete type
fping.c:1929:23: error: dereferencing pointer to incomplete type
fping.c:1929:23: error: dereferencing pointer to incomplete type
fping.c:1931:18: error: dereferencing pointer to incomplete type
fping.c:1954:39: error: dereferencing pointer to incomplete type
fping.c:1974:10: error: ‘ICMP_SOURCEQUENCH’ undeclared (first use in this functi on)
fping.c:1975:10: error: ‘ICMP_REDIRECT’ undeclared (first use in this function)
fping.c:1976:10: error: ‘ICMP_TIMXCEED’ undeclared (first use in this function)
fping.c:1977:10: error: ‘ICMP_PARAMPROB’ undeclared (first use in this function)
fping.c:1980:24: error: dereferencing pointer to incomplete type
fping.c:1981:15: error: dereferencing pointer to incomplete type
fping.c:1981:15: error: dereferencing pointer to incomplete type
fping.c:1981:15: error: dereferencing pointer to incomplete type
fping.c:1981:15: error: dereferencing pointer to incomplete type
fping.c:1982:15: error: dereferencing pointer to incomplete type
fping.c:1982:15: error: dereferencing pointer to incomplete type
fping.c:1982:15: error: dereferencing pointer to incomplete type
fping.c:1982:15: error: dereferencing pointer to incomplete type
fping.c:1985:23: error: dereferencing pointer to incomplete type
fping.c:1985:23: error: dereferencing pointer to incomplete type
fping.c:1985:23: error: dereferencing pointer to incomplete type
fping.c:1985:23: error: dereferencing pointer to incomplete type
fping.c:1987:32: error: dereferencing pointer to incomplete type
fping.c:2013:10: error: ‘ICMP_TSTAMP’ undeclared (first use in this function)
fping.c:2014:10: error: ‘ICMP_TSTAMPREPLY’ undeclared (first use in this functio n)
fping.c:2015:10: error: ‘ICMP_IREQ’ undeclared (first use in this function)
fping.c:2016:10: error: ‘ICMP_IREQREPLY’ undeclared (first use in this function)
fping.c:2017:10: error: ‘ICMP_MASKREQ’ undeclared (first use in this function)
fping.c:2018:10: error: ‘ICMP_MASKREPLY’ undeclared (first use in this function)
Makefile:295: recipe for targetfping.o' failed
make[2]: ** [fping.o] Error 1
make[2]: Leaving directory /home/fping-3.5/src'
Makefile:292: recipe for targetall-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory /home/fping-3.5'
Makefile:232: recipe for targetall' failed
make: *** [all] Error 2

(This is more of for your information issue really)

Not sure if this effects other platforms or if it is PEBKAC but in order to build from source with IPv6 support on FreeBSD (on 9.2-RELEASE and 10-.0-RELEASE) I needed to pull in sys/types.h. This may go in as a ports patch for FreeBSD or maybe you want to fix it here. Cheers.

--- src/fping.h.orig   2014-02-11 08:45:57.099772218 -0500
+++ src/fping.h        2014-02-11 08:47:08.567771444 -0500
@@ -4,6 +4,7 @@
 #define __APPLE_USE_RFC_3542 1

 #include <sys/socket.h>
+#include <sys/types.h>
 #include <netinet/in.h>

 #ifndef IPV6

You had some problem with preparing 3.4 release.

If download http://fping.org/dist/fping-3.4.tar.gz and compile it then I have:

fping -v

fping: Version 3.4
fping: comments to [email protected]

man fping | grep "3.3"

fping 3.3-rc1 2012-07-20 FPING(8)

If perform autogen.sh, configure, make dist using sources from this git then all is fine.

Probably need to improve somehow release process to avoid such cases :)

Initially reported at http://bugs.debian.org/673348 by Robert Henney [email protected]:

very minor documentation inconsistency in that several options which take numeric arguments are shown with an underscored "n" (eg. "-in", "-bn", and "-rn") but at the same time several others are not (eg. "-c", "-C", and "-p").

This seems still the case with 3.2rc1.

Please include an RPM spec file with the source. For example:

Summary: send ICMP echo probes to multiple hosts
Name: fping
Version: 3.2
Release: 1
License: MIT
Group: Applications/System
Source0: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot

%description
fping is a program to send ICMP echo probes to network hosts, similar to ping,
but much better performing when pinging multiple hosts. fping has a very long
history: Roland Schemers did publish a first version of it in 1992 and it has
established itself since then as a standard tool for network diagnostics and
statistics.

%prep
%setup -q

%build
%configure

make

%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
/usr/sbin/fping
/usr/share/man/man8/fping.8.gz

%post
if [ -x /usr/sbin/setcap ]; then
    setcap cap_net_raw+ep /usr/sbin/fping
else
    chmod 1777 /usr/sbin/fping
fi

%changelog
* Mon Jul 16 2012 Stephen Schaefer<[email protected]>
- Initial build

The -n flag in fping is used to "show targets by name". fping6 also offers this flag according to usage(), but it doesn't work:

[pavlicek@fisadm ~]$ fping6 -n 2a00:1450:4016:801::1014
2a00:1450:4016:801::1014 is alive
[pavlicek@fisadm ~]$ host 2a00:1450:4016:801::1014
4.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.1.0.8.0.6.1.0.4.0.5.4.1.0.0.a.2.ip6.arpa domain name pointer muc03s02-in-x14.1e100.net.
[pavlicek@fisadm ~]$

fping6 should say "muc03s02-in-x14.1e100.net is alive".

Initially reported at http://bugs.debian.org/525431 by Peter Folk [email protected]. Citing his report:

I use fping a lot, to monitor several hundred hosts. I did not notice a problem until recently, but now when I'm pinging a host that is down along with others that are up, after a while fping gets confused about which host is which and ends up saying the wrong host is down. It's unclear whether it's attributing other packets to the wrong hosts, or only the ones that are down.

Case in point:

# 10.7.2.4 is known down, 10.3.1.5 is known up
fping -Al 10.3.1.5 four other random hosts 10.7.2.4
# normal response:
10.3.1.5 : [0], 96 bytes, 114 ms (114 avg, 0% loss)
10.3.1.5 : [1], 96 bytes, 205 ms (159 avg, 0% loss)
10.3.1.5 : [2], 96 bytes, 26.0 ms (115 avg, 0% loss)
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.7.2.4
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.7.2.4
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.7.2.4
# ...
# Then after a while (an hour or so):
10.7.2.4 : [0], 96 bytes, 114 ms (114 avg, 0% loss)
10.7.2.4 : [1], 96 bytes, 205 ms (159 avg, 0% loss)
10.7.2.4 : [2], 96 bytes, 26.0 ms (115 avg, 0% loss)
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.3.1.5
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.3.1.5
ICMP Host Unreachable from 10.7.0.6 for ICMP Echo sent to 10.3.1.5

Using tcpdump, I can verify that the Host Unreachable messages are correct (from 10.7.0.6 for ICMP Echo sent to 10.7.2.4), but fping is reporting them wrong. It doesn't happen with every set of arguments and because it takes some time to reproduce, I haven't been able to find an exact cause (minimal test case). That said, the bug appears to have been introduced recently (say, some time this year).

His report is from 24 Apr 2009 and since there was no upload of fping to Debian in 2009, it may have been introduced by one of the uploads in 2008:

http://packages.qa.debian.org/f/fping/news/20081018T113203Z.html
http://packages.qa.debian.org/f/fping/news/20080303T233206Z.html

The next older upload was from 2006 so if the issue was really introduced by some Debian patches, it's likely that it was a patch introduced in one of those two uploads.

You can find the according Debian source packages at http://snapshot.debian.org/package/fping/

Did you considered deploying any of these?

I believe the fix a5828a2 for #13 "(Debian #308695): don't remove hosts if sendto returns an error." has broken fping in case of permanent sendto() failure.

After a5828a2, send_ping() always returns 1 and non-loop mode fping would hang if sendto() always fails (e.g. when there is no default route).

# sudo ip -6 route del default
# sudo ./fping6    2002:1:1::
2002:1:1:: error while sending ping: Network is unreachable

2002:1:1:: error while sending ping: Network is unreachable

2002:1:1:: error while sending ping: Network is unreachable
...

A possible fix is to increase h->waiting on send failure so the entry can be removed after several retries in non-loop mode:

diff --git a/src/fping.c b/src/fping.c
index 32b1cb0..5e02ef5 100644
--- a/src/fping.c
+++ b/src/fping.c
@@ -1463,7 +1463,9 @@ int send_ping( int s, HOST_ENTRY *h )

         h->num_sent++;
         h->num_sent_i++;
+        h->waiting++;
         num_pingsent++;
+        last_send_time = h->last_send_time;
         free( buffer );
         return(1);
     }

Initially reported at https://bugs.launchpad.net/ubuntu/+source/fping/+bug/649646

Minimum ping data given by sizeof (PING_DATA) gives 12b on x32, but 24bytes on x64. This makes default ping size 68bytes (76 with icmp hdr) on x64 because default_ping_data is calculated as PING_DATA + 44

Non trivial bug, but still.
(We had some APC PDUs that didn't give a reply when ping data was as with this bug > 56bytes)

Patch at https://launchpadlibrarian.net/56656232/fping_sizeof_fix.patch