schweikert / fping Goto Github PK
View Code? Open in Web Editor NEWHigh performance ping tool
Home Page: https://fping.org
License: Other
High performance ping tool
Home Page: https://fping.org
License: Other
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
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
(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
The code should be made more modern and use sockaddr_storage for unified storage of ipv4 and ipv6 addresses.
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)
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
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]
there is a lot of trailing whitespace in the code. as part of the cleanup, it could be nuked with the attached patch :)
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: Version 3.4
fping: comments to [email protected]
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 :)
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.
Solaris 8 needs a patch to compile
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
Possible to add a feature for logging result ?
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
Did you considered deploying any of these?
Different tests using Fping 3.4 (port or manually source compiled) on freebsd (9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825)
Scenario : the host we want to fping is not alive
A) Cases
case 1) :
fping ip_hostdown when ip_hostdown is not located on local network :
result is ALWAYS = ip_hostdown is unreachable
case 2)
fping ip_hostdown when ip_hostdown is located on local network :
result is very rarely = ip_hostdown is unreachable
result is almost always (mainly if i give consecutive tries):
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
ip_hostdown error while sending ping: Host is down
......
......
==> fping get stuck and never stop if i don't ctrc-c
When i ctrl-c to stop stucked fping ==> ^Cip_hostdown is unreachable
B) source code fping 3.4 : "error while sending ping" is in source code fping.c line 1581
"Host is down" doesn't come from fping source code.
C) Linux test (many version of kernel/distribution) with compiled version of fping 3.4
result is always : ip_hostdown is unreachable
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.
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.
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?
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/
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
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.
help output goes to stderr - it should go to stdout instead
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
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/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.
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.
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 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.
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".
Is there a easy guide to compile fping using mingw?
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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 ) );
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
It would be nice to have this in fping as well:
http://anarcat.koumbit.org/2013-12-03-announcing-prettier-noping
octo/liboping#3
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.
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
fping 3.7 does a segmentation fault when running in loop mode. Reported by Vlad Glagolev
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
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 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/fping/src# ./fping6 fe80::baac:6fff:fe7d:e934
fe80::baac:6fff:fe7d:e933 is alive
:
fe80::baac:6fff:fe7d:e934 is unreachable
:
/fping/src# ./fping6 2aab::baac:6fff:fe7d:e933/fping/src# ./fping6 2aab::baac:6fff:fe7d:e934
2aab::baac:6fff:fe7d:e933 is alive
:
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?
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]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.