Command-line argument --icmp-ipid updates variable icmp_ip_id which is never used to set the identifier field in the ICMP header of echo requests (icmp type 8). Instead, in sendicmp.c getpid() is used to set variable icmp->un.echo.id which I'm guessing is the default behavior (random identifier).

First, fantastic utility, it has come in great handy!

I've been invoking hping in a context, where I do two things:
capture both the Stdout where each packet result is logged
and
capture statistics of the entire set of packets.

I noticed hping's statistics are piped to stderr, and for a point of comparison I checked that Mac OS X's ping logs the summary at the end of Stdout.
So I became curious, whether there's a specific design motivation for logging statistics on Stderr rather than at the end of Stdout? :)

https://github.com/antirez/hping/blob/master/statistics.c#L32-L39

root@guru:/home/sait32/Downloads/hping-master# make
gcc -c -O2 -Wall -g main.c
gcc -c -O2 -Wall -g getifname.c
gcc -c -O2 -Wall -g getlhs.c
gcc -c -O2 -Wall -g parseoptions.c
gcc -c -O2 -Wall -g datafiller.c
gcc -c -O2 -Wall -g datahandler.c
gcc -c -O2 -Wall -g gethostname.c
gcc -c -O2 -Wall -g binding.c
gcc -c -O2 -Wall -g getusec.c
gcc -c -O2 -Wall -g opensockraw.c
gcc -c -O2 -Wall -g logicmp.c
gcc -c -O2 -Wall -g waitpacket.c
gcc -c -O2 -Wall -g resolve.c
gcc -c -O2 -Wall -g sendip.c
gcc -c -O2 -Wall -g sendicmp.c
In file included from /usr/include/string.h:494,
from sendicmp.c:19:
In function ‘memcpy’,
inlined from ‘send_icmp_other’ at sendicmp.c:256:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:10: warning: ‘__builtin_memcpy’ forming offset [21, 28] is out of the bounds [0, 20] of object ‘icmp_ip’ with type ‘struct myiphdr’ [-Warray-bounds]
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sendicmp.c: In function ‘send_icmp_other’:
sendicmp.c:197:17: note: ‘icmp_ip’ declared here
struct myiphdr icmp_ip;
^~~~~~~
gcc -c -O2 -Wall -g sendudp.c
gcc -c -O2 -Wall -g sendtcp.c
gcc -c -O2 -Wall -g cksum.c
gcc -c -O2 -Wall -g statistics.c
gcc -c -O2 -Wall -g usage.c
gcc -c -O2 -Wall -g version.c
gcc -c -O2 -Wall -g antigetopt.c
gcc -c -O2 -Wall -g sockopt.c
gcc -c -O2 -Wall -g listen.c
listen.c: In function ‘listenmain’:
listen.c:77:4: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(stdoutFD, p, size-(p-ip_packet));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -c -O2 -Wall -g sendhcmp.c
gcc -c -O2 -Wall -g memstr.c
gcc -c -O2 -Wall -g rtt.c
rtt.c: In function ‘rtt’:
rtt.c:43:3: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (i=0; i<TABLESIZE; i++)
^~~
rtt.c:48:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’
if (i != TABLESIZE)
^~
gcc -c -O2 -Wall -g relid.c
gcc -c -O2 -Wall -g sendip_handler.c
gcc -c -O2 -Wall -g libpcap_stuff.c
libpcap_stuff.c:19:10: fatal error: net/bpf.h: No such file or directory
#include <net/bpf.h>
^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:66: libpcap_stuff.o] Error 1
root@guru:/home/sait32/Downloads/hping-master#

If I need to change to a multithreaded approach, what are some things to watch out for。

can you why this error

I get this compiler warning on Mac OS.

This looks like a buffer overflow that needs to get fixed.

gcc -c -O2 -Wall    -g  scan.c
scan.c:459:4: warning: 'memcpy' will always overflow; destination buffer has size 8, but size argument is 20 [-Wbuiltin-memcpy-chk-size]
                        memcpy(&icmp, p, sizeof(subtcp));
                        ^
1 warning generated.

Hi,

To package hping for some linux distros it would be super convenient to have an official tarball, but I couldn't find one. The README states:

The hping3 primary download site is the following:

http://www.hping.org

But http://www.hping.org/download.php redirects to github:

Hping is no longer actively developed, however from time to time, changes are submitted by users and are integrated into the main source tree. The development HQ is the Hping Github repository, please grab sources from Github.

So could you make a release so that there is a tarball available on github, please?

In sendicmp.c the sequence number header field of ICMP echo requests is set to _icmp_seq which is a counter. However in little-endian architectures (x86) we need to change the byte order to big-endian so that it meets the network order convention. We can use htons(_icmp_seq) for this.

Please add 64bit support

sed -i 's|/usr/lib|/usr/lib/ /usr/lib64/|' configure

Without this sed get

usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -ltcl

libpcap-devel not have net/bpf.h but pcap-bpf.h

rpm -ql libpcap-devel
...
/usr/include/pcap-bpf.h
...

I use this sed to fix include

sed -i 's|net/bpf.h|pcap-bpf.h|' script.c libpcap_stuff.c

Without this sed get

[    9s] libpcap_stuff.c:20:21: fatal error: net/bpf.h: No such file or directory
[    9s]  #include <net/bpf.h>
[    9s]                      ^
[    9s] compilation terminated.
[    9s] Makefile:71: recipe for target 'libpcap_stuff.o' failed

I use hping to monitor the network. I find hping cases core dump file.
I use gdb debug that looks like:

Is it possible somewhere:

1. double free/free
2. Heap crossing
3. or someting else？

thanks

I happened to run across this while writing a script to map the first and second octet of source addresses to the x and y of a 256 x 256 image. It seems there is something amiss with the random function used.

You can see there's gaps in the random distribution. Ideally the distribution should be smooth.

I have added support for $(DESTDIR), docs, man pages too for French in Makefile.in

cat hping-3.0.0_alpha_1-Makefile.in.patch 
--- Makefile.in.orig    2014-12-25 15:01:43.000000000 +0100
+++ Makefile.in 2014-12-26 08:06:25.681410513 +0100
@@ -9,14 +9,19 @@
 CC= gcc
 AR=/usr/bin/ar
 RANLIB=/usr/bin/ranlib
-CCOPT= -O2 -Wall @PCAP_INCLUDE@ @TCL_INC@ @USE_TCL@
+CCOPT= $(CFLAGS) -O2 -Wall @PCAP_INCLUDE@ @TCL_INC@ @USE_TCL@
 DEBUG= -g
 #uncomment the following if you need libpcap based build under linux
 #(not raccomanded)
 COMPILE_TIME=
-INSTALL_MANPATH=@MANPATH@
 @PCAP@

+DOCS = AUTHORS *BUGS CHANGES COPYING NEWS README TODO
+DOCS_EN = docs/*.txt docs/AS-BACKDOOR docs/HPING2-IS-OPEN docs/MORE-FUN-WITH-IPID
+DOCS_FR = docs/french/*.txt docs/french/AS-BACKDOOR docs/french/HPING2-IS-OPEN docs/french/MORE-FUN-WITH-IPID
+MANS = docs/hping2.8 docs/hping3.8
+MANS_FR = docs/french/hping2-fr.8
+
 ARSOBJ = ars.o apd.o split.o rapd.o

 OBJ=   main.o getifname.o getlhs.o \
@@ -72,17 +77,18 @@
        rm -rf hping3 *.o byteorder byteorder.h systype.h Makefile libars.a .depend
        rm -rf hping3 *.o byteorder byteorder.h systype.h Makefile libars.a .depend

 install: hping3
-       cp -f hping3 /usr/sbin/
-       chmod 755 /usr/sbin/hping3
-       ln -s /usr/sbin/hping3 /usr/sbin/hping
-       ln -s /usr/sbin/hping3 /usr/sbin/hping2
-       @if [ -d ${INSTALL_MANPATH}/man8 ]; then \
-               cp ./docs/hping3.8 ${INSTALL_MANPATH}/man8; \
-               chmod 644 ${INSTALL_MANPATH}/man8/hping3.8; \
-       else \
-               echo "@@@@@@ WARNING @@@@@@"; \
-               echo "Can't install the man page: ${INSTALL_MANPATH}/man8 does not exist"; \
-       fi
+       install -m 0755 -d $(DESTDIR)/usr/sbin
+       install -m 0755 -d $(DESTDIR)/usr/share/man/man8
+       install -m 0755 -d $(DESTDIR)/usr/share/man/fr/man8
+       install -m 0755 -d $(DESTDIR)/usr/share/doc/packages/hping/docs/french
+       install -m 0755 hping3 $(DESTDIR)/usr/sbin/
+       ln -s /usr/sbin/hping3 hping
+       ln -s /usr/sbin/hping3 hping2
+       install -m 0644 $(MANS) $(DESTDIR)/usr/share/man/man8/
+       install -m 0644 $(MANS_FR) $(DESTDIR)/usr/share/man/fr/man8/
+       install -m 0644 $(DOCS) $(DESTDIR)/usr/share/doc/packages/hping/
+       install -m 0644 $(DOCS_EN) $(DESTDIR)/usr/share/doc/packages/hping/docs/
+       install -m 0644 $(DOCS_FR) $(DESTDIR)/usr/share/doc/packages/hping/docs/french/

 strip: hping3
        @ls -l ./hping3

This changes fix build

I use this sed to fix build with scan.c

sed -i 's|icmp, p, sizeof(subtcp|icmp, p, sizeof(icmp|' scan.c

Without this sed get

[   19s] I: Statement is overflowing a buffer
[   19s] E: hping bufferoverflow /usr/include/bits/string3.h:51

I use this patch to fix build with ars.c

cat hping-3.0.0_alpha_1-ars.c.patch 
--- ars.c.orig  2014-12-25 15:01:43.000000000 +0100
+++ ars.c       2014-12-26 07:50:20.883410513 +0100
@@ -481,8 +481,8 @@
                sum = (sum >> 16) + (sum & 0xffff);
                sum += (sum >> 16);
                return (u_int16_t) ~sum;
-       } else {
-               assert("else reached in ars_multi_cksum()" == "");
+//     } else {
+//             assert("else reached in ars_multi_cksum()" == "");
        }
        return 0; /* unreached, here to prevent warnings */
 }

Without this patch get

[   16s] I: Expression compares a char* pointer with a string literal.
[   16s]    Usually a strcmp() was intended by the programmer
[   16s] E: hping stringcompare ars.c:485

Please correct these build warnings and release new commit when is all fixed, too Issue #9

[    9s] getifname.c:343:35: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness [-Wpointer-sign]
[    9s]   if (getsockname(sock_rt, (struct sockaddr *)&iface_out, &len) == -1 ) {
[    9s]                                    ^
[    9s] In file included from getifname.c:14:0:
[    9s] /usr/include/sys/socket.h:127:12: note: expected 'socklen_t * __restrict__' but argument is of type 'int *'
[    9s]  extern int getsockname (int __fd, __SOCKADDR_ARG __addr,
[    9s]             ^
[    9s] getifname.c: In function 'get_if_name':
[    9s] getifname.c:61:11: warning: 'sa.sin_addr.s_addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
[    9s]      printf("DEBUG: Output interface address: %s\n",
[    9s]            ^
...
[   11s] waitpacket.c: In function 'wait_packet':
[   11s] waitpacket.c:691:57: warning: 'tstamp' may be used uninitialized in this function [-Wmaybe-uninitialized]
[   11s]                  if (hz > 0 && opt_clock_skew) clock_skew(hz,tstamp,rttms);
[   11s]                                                          ^
[   11s] waitpacket.c:611:8: note: 'tstamp' was declared here
[   11s]   __u32 tstamp, echo;
[   11s]         ^
...
[   11s] listen.c: In function 'listenmain':
[   11s] listen.c:77:9: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
[   11s]     write(stdoutFD, p, size-(p-ip_packet));
[   11s]          ^
...
[   11s] libpcap_stuff.c:26:6: warning: variable 'on' set but not used [-Wunused-but-set-variable]
[   11s]   int on;
[   11s]       ^
[   11s] libpcap_stuff.c: In function 'pcap_recv':
[   11s] libpcap_stuff.c:61:19: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
[   11s]                  p = (unsigned char*) pcap_next(pcapfp, &hdr);
[   11s]                    ^
...
[   12s] ip_opt_build.c: In function 'ip_opt_build':
[   12s] ip_opt_build.c:28:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsize
of-pointer-memaccess]
[   12s]      memset(ip_opt, 1, sizeof(ip_opt));
[   12s]                              ^
...
[   12s] random.c:32:7: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
[   12s]    read(fd, rc4_sbox, 256);
[   12s]        ^
...
[   12s] scan.c:458:6: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
[   12s]     p = packet+linkhdr_size+iphdrlen;
[   12s]       ^
...
[   12s] adbuf.c: In function 'adbuf_addchar':
[   12s] adbuf.c:130:22: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
[   12s]    unsigned char *p = b->buf + adbuf_used(b);
[   12s]                       ^
...
[   13s] ars.c:909:20: warning: variable 'ip' set but not used [-Wunused-but-set-variable]
[   13s]   struct ars_iphdr *ip;
[   13s]                     ^
[   13s] apd.c: In function 'ars_decode_hex':
[   13s] apd.c:823:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]
[   13s]   return saved;
[   13s]   ^
[   13s] apd.c: In function 'ars_decode_string':
[   13s] apd.c:852:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]
[   13s]   return saved;
[   13s]   ^
[   13s] apd.c: In function 'ars_d_set_data':
[   13s] apd.c:889:7: warning: variable 'err' set but not used [-Wunused-but-set-variable]
[   13s]    int err, blen;
[   13s]        ^

Tip add in sources where you get

p = 
   ^

#include <unistd.h>

Please fix too gethostbyname

[   23s] hping.x86_64: I: binary-or-shlib-calls-gethostbyname /usr/sbin/hping3
[   23s] The binary calls gethostbyname(). Please port the code to use getaddrinfo().

I install hping using: brew install hping , and when I run it I got the error: Sorry, this hping binary was compiled without TCL scripting support.

We ran into an issue when using Python subprocess to call hping3 command under a Python web app server uWSGI, however the hping3 process hung forever.

It turned out that this malfunction ascribes to signal, uWSGI blocks SIGALRM, and fork(2) + exec(2) inherits the signal mask, so that the forked hping3 process starts with SIGALRM being blocked. Unfortunately SIGALRM plays a significant role in the hping app, and everything cracked.

According to SUSv4, it is recommended that signal sensitive software had better "assume that they start certain signals set unblocked":

This volume of POSIX.1-2017 specifies that signals set to SIG_IGN remain set to SIG_IGN, and that the new process image inherits the signal mask of the thread that called exec in the old process image. This is consistent with historical implementations, and it permits some useful functionality, such as the nohup command. However, it should be noted that many existing applications wrongly assume that they start with certain signals set to the default action and/or unblocked. In particular, applications written with a simpler signal model that does not include blocking of signals, such as the one in the ISO C standard, may not behave properly if invoked with some signals blocked. Therefore, it is best not to block or ignore signals across execs without explicit reason to do so, and especially not to block signals across execs of arbitrary (not closely cooperating) programs.
(from susv4-2018/functions/exec)

Therefore I was wondering if it's appropriate to make some minor improvement to avoid further issues around this cause?

I'll admit, i'm not a coder nor a programmer. Came across this error trying to install hping from the github set of files, specifically following the INSTALLATION instructions. Anything jump out? Looks like a great tool, wanted to play with it.

sh-3.2# ./configure
build byteorder.c...
byteorder.c:86:41: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
printf("sizeof(unsigned int) = %d\n", sizeof(unsigned int));
~~ ^~~~~~~~~~~~~~~~~~~~
%lu
1 warning generated.

create byteorder.h...

system type: DARWIN

LIMITWHENSUID: -DLIMITWHENSUID
FORCE_LIBPCAP:
HAVE_PROC :
LIBPCAP : PCAP=libpcap/libpcap.a
PCAP_INCLUDE : -I./libpcap
MANPATH : /usr/local/man

(to modify try configure --help)

creating Makefile...
now you can try `make'
sh-3.2# make --ok, so I continue on. Why not??
gcc -c -O2 -Wall -I./libpcap -g -DLIMITWHENSUID getlhs.c
getlhs.c:145:2: error: expected expression
else if ( strstr(ifname, "lo") )
^
1 error generated.
make: *** [getlhs.o] Error 1

sh-3.2# make install ---eh, nothing to lose, so I tried.
gcc -c -O2 -Wall -I./libpcap -g -DLIMITWHENSUID getlhs.c
getlhs.c:145:2: error: expected expression
else if ( strstr(ifname, "lo") )
^
1 error generated.
make: *** [getlhs.o] Error 1
sh-3.2#

Is IPv6 support possible with hping3?

Sometimes hping reports an RTT that is 1000ms larger than all the other values. However, it doesn't actually pause for 1s at that line, it appears that the time is misreported.

      HPING 10.65.1.1 (eth0 10.65.1.1): S set, 40 headers + 0 data bytes
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=0 win=29200 rtt=3.9 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=1 win=29200 rtt=1003.7 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=2 win=29200 rtt=3.4 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=3 win=29200 rtt=3.0 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=4 win=29200 rtt=2.7 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=5 win=29200 rtt=2.3 ms
      len=44 ip=10.65.1.1 ttl=63 DF id=0 sport=3000 flags=SA seq=6 win=29200 rtt=2.0 ms
...

After digging in the codebase, it looks like the problem is this: when storing the timestamp of the outgoing ping, hping does

secs = time(NULL);
usecs = get_usec();

This can fail if the time wraps to the next second between the call to time() and get_usecs().

About to send packet:

• clock is at 9.999999s, we read the second part as 9

• clock wraps to 1.000000, we read the usec part as 0

• record that packet was sent at 9.000000s

Receive response

• clock is at 10.001000

• read seconds as 10

• read usec as 1000

Incorrectly calculate RTT as 10.001000 - 9.000000 = 1.001sec.

Best fix would be to remove the get_usec utility function and call gettimeofday() exactly once and to use the returned tv_sec and tv_usec from the same call.

Hi is this availible for mac in zsh. Also if it is it isn't letting me download. Also is there a repl version that I can use?

而且已经安装了libpcap-devel

I tried to run tcp hping3
sudo hping3 -S -p 22 10.1.0.8 -c 5
HPING 10.1.0.8 (eth0 10.1.0.8): S set, 40 headers + 0 data bytes
len=44 ip=10.1.0.8 ttl=64 DF id=0 sport=22 flags=SA seq=0 win=29200 rtt=1.6 ms
len=44 ip=10.1.0.8 ttl=64 DF id=0 sport=22 flags=SA seq=1 win=29200 rtt=3.9 ms
len=44 ip=10.1.0.8 ttl=64 DF id=0 sport=22 flags=SA seq=2 win=29200 rtt=6.0 ms
len=44 ip=10.1.0.8 ttl=64 DF id=0 sport=22 flags=SA seq=3 win=29200 rtt=4.4 ms
len=44 ip=10.1.0.8 ttl=64 DF id=0 sport=22 flags=SA seq=4 win=29200 rtt=11.9 ms

--- 10.1.0.8 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.6/5.5/11.9 ms

If I measure latency using sockperf tool avg latency is getting ~ 0.5ms
(sockperf.bin ping-pong -i 10.1.0.8 -p 8302 -t 15 --pps=max )

Does internal way of measuring tcp rtt from hping3 and tcp latency from sockperf same?
Am I doing anything wrong here?
Could you please help with this issue?

1 microsecond = 1.0 × 10^-6 seconds
so u10000，is 100 packets for second
u1000，is 1000 packets for second

Hello,

Hping3 fails to lookup for interfaces with index greater to 16 because the internal buffer to store interfaces is 16 entries large.
This result in hping3 not being usable for interfaces after this limit.
On todays computers we can have way more interfaces.
Can you increase the limit to a higher value (like 4096 for example) ?

In file 'getifname.':
- struct ifreq ibuf[16],
+ struct ifreq ibuf[4096],

Hi, i'm interested in this parameter (--tcp-mss) but with my Centos 7 version i can't find it!
Why? Can i download a version that has this parameter?

My Centos 7 version is: hping3-0.0.20051105-24.el7.x86_64

Regards

Is it possible to change this license? I am a fellow Pivotal person. We'd love to use hping in Cloud Foundry. License makes that hard.

I use hping to send tcp packet.
Sometime I find it has no rtt value.

1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

min, avg and max are 0?
why?

Right FSF Address is, please correct this

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301  USA

Get this

[   26s] hping.x86_64: W: incorrect-fsf-address /usr/share/doc/packages/hping/COPYING
[   26s] The Free Software Foundation address in this file seems to be outdated or
[   26s] misspelled.  Ask upstream to update the address, or if this is a license file,
[   26s] possibly the entire file with a new copy available from the FSF.

When using

hping3 -2 --scan 0-100 192.168.1.1

this results in no open ports detected (even though I know the target has DNS running). Analysis with Wireshark shows that the UDP messages that hping3 sends contain a bogus length (quite random really).

Note:

This is possibly due to the scan.c:sender function not taking the -2 option into account and only calls send_tcp().

The following

hping3 -1 <address> -i u100

reports non-existent duplicates packets for icmp_seq=65200. This happens at exactly the point when the icmp_seq counter rolls over. This does not happen in our testing every time, but it does happen most times.

example output log

[snip]
len=28 ip=172.30.0.2 ttl=64 id=59018 icmp_seq=65198 rtt=5.8 ms
len=28 ip=172.30.0.2 ttl=64 id=59019 icmp_seq=65199 rtt=5.6 ms
len=28 ip=172.30.0.2 ttl=64 id=59020 icmp_seq=65200 rtt=5.5 ms
len=28 ip=172.30.0.2 ttl=64 id=59021 icmp_seq=65201 rtt=5.4 ms
len=28 ip=172.30.0.2 ttl=64 id=59022 icmp_seq=65202 rtt=5.3 ms
[snip]
len=28 ip=172.30.0.2 ttl=64 id=59354 icmp_seq=65534 rtt=6.9 ms
len=28 ip=172.30.0.2 ttl=64 id=59355 icmp_seq=65535 rtt=6.8 ms
DUP! len=28 ip=172.30.0.2 ttl=64 id=59356 icmp_seq=65200 rtt=45.5 ms
len=28 ip=172.30.0.2 ttl=64 id=59357 icmp_seq=1 rtt=0.0 ms
len=28 ip=172.30.0.2 ttl=64 id=59358 icmp_seq=2 rtt=0.0 ms
len=28 ip=172.30.0.2 ttl=64 id=59359 icmp_seq=3 rtt=0.0 ms
[snip]

I believe that program is now called "hping3". Current COPYING file seems not to cover it:
https://github.com/antirez/hping/blob/master/COPYING#L1

It appears that I cannot get hping3 to ping a host in a remote network when connected via VPN tunnel. I'm not sure whether the issue is that I have too many interfaces (I do lots of virtualization on my laptop and currently have 48 interfaces - mainly due to LXD containers).

I've tried forcing which interface to use via the -I tun0 flag but no joy - hping3 always binds to lo for hosts on the remote subnet.

List of interfaces (too many to list here - unless explicitly requested):

$ ip l l | awk '/^[0-9]*:/ {print}'| wc -l
48

Routing info (relevant route listed):

$ ip r l | egrep 10.2.20
10.2.20.0/24 via 10.64.192.14 dev tun0 

Route to remote host:

[Fri Jul 27 17:33:31 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ ip r g 10.2.20.74
10.2.20.74 via 10.64.192.14 dev tun0  src 10.64.192.13 
    cache 

Attempt to hping:

[Fri Jul 27 17:29:06 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ sudo ./hping3 -I tun0 -S -p 443 10.2.20.74
HPING 10.2.20.74 (lo 10.2.20.74): S set, 40 headers + 0 data bytes
^C
--- 10.2.20.74 hping statistic ---
5 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

A simple ping:

[Fri Jul 27 17:31:32 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ ping -c4 10.2.20.74
PING 10.2.20.74 (10.2.20.74) 56(84) bytes of data.
From 10.64.192.222: icmp_seq=1 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=1 ttl=62 time=12.1 ms
From 10.64.192.222: icmp_seq=2 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=2 ttl=62 time=12.5 ms
From 10.64.192.222: icmp_seq=3 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=3 ttl=62 time=13.0 ms
From 10.64.192.222: icmp_seq=4 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=4 ttl=62 time=11.6 ms

--- 10.2.20.74 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 11.670/12.542/13.082/0.436 ms

Let me know what else to provide to help narrow the problem.

I use it “hping -F -s 62000 -p 61000 X.X.X.X -c 3”
I found that the source port is incremented.
It looks like 62000, 62001, 62002

How can I send multiple packets using the same source port?

thanks

http://www.hping.org/

The domain can not be resolved.

You might want to improve the response message in line 147 of parseoptions.c
It gave me a good chuckle, but didn't help with my troubleshooting.

fprintf(stderr, "RECTUM\n");

I am transferring a file with these parameters:
hping3 10.0.1.5 --icmp --sign data --file target.txt -d 100 -u -C 11
Listener:
hping3 10.0.1.4 --listen data -I eth0

File contains:
Lorem ipsum dolor sit amet, sed ad nibh recusabo, eos albucius periculis constituto no. Per exerci dicunt an. Ut impetus saperet labores sed.

I receive:
Lorem ipsum dolor sit amet, sed ad nibh recusabo, eos albucius periculis constituto no. Per exerci dicunt an. Ut impetus saperet labores sed.
Lorem ipsum dolor sit amet, sed ad nibh recusabo, eos albucius periculis constituto no. Per exer

All my transfers are like this and depending on my data frame value I get more or less but rarely the exact file. I viewed the pcaps, and there seems to be 1 or 2 extra packets sent that are exactly the same as the very first 1-2 packets. To get around this, I base64 encode it as base64 data has "==" delimiters. I then "cut" it on the first "==" so it is no longer repetitive.

As an example (once the data being sent is base64 encoded):

$1 - sending IP

$2 - signature

$3 - interface

$4 - file to save as

Usage: hping3 [sender ip] --listen [signature] -I [interface] > [file]

hping3 $1 --listen $2 -I $3 > ./.temp1
trap " " INT
echo "past trap"
cut -f1 -d '=' ./.temp1 | tr -d '\n' > ./.temp2
echo -n '==' | cat ./.temp2 - > $4
rm ./.temp2 & rm ./.temp1

I am sending this data from one VM to another and do not see any reason for retransmitted packets.

Right click and save the file > Change the file from *.png to *.pcapng to view in wireshark to see the extra packet that was sent. It's not just in this ICMP type either, type 0 did this as well.

I am facing some issues when installing hping on kali-linux-docker. anyone can help on this?
##Local Host #####

docker info
Containers: 6
 Running: 0
 Paused: 0
 Stopped: 6
Images: 10
Server Version: 1.12.6
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 95
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host bridge null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.41-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.951 GiB
Name: moby
ID: N3BG:IOKH:FJPX:WZ2H:52KE:IOZM:NU2I:7WLI:HOEH:ES5H:J7AM:WXYU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 19
 Goroutines: 29
 System Time: 2017-01-19T07:52:24.066608467Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

##Docker image information###
docker images -a kalilinux/kali-linux-docker
REPOSITORY TAG IMAGE ID CREATED SIZE
kalilinux/kali-linux-docker latest dc19a2669ec2 3 weeks ago 1.307 GB

error message:

root@90f655fa08f0:/hping3# ./configure
build byteorder.c...
create byteorder.h...
./configure: 1: ./configure: -: not found
==> WARNING: no Tcl header files found!

system type: LINUX

LIBPCAP : PCAP=-lpcap
PCAP_INCLUDE :
MANPATH : /usr/local/man
USE_TCL :
TCL_VER :
TCL_INC :
LIBTCL : -ltcl -lm -lpthread
TCLSH :

(to modify try configure --help)

creating Makefile...
creating dependences...
In file included from ars.h:20:0,
from apd.c:19:
bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

error can not find the byte order for this architecture, fix bytesex.h

In file included from apd.c:19:0:
ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

In file included from ars.h:20:0,
from ars.c:24:
bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

error can not find the byte order for this architecture, fix bytesex.h

In file included from ars.c:24:0:
ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

In file included from ars.h:20:0,
from arsglue.c:7:
bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

error can not find the byte order for this architecture, fix bytesex.h

In file included from arsglue.c:7:0:
ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

In file included from ars.h:20:0,
from rapd.c:11:
bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

error can not find the byte order for this architecture, fix bytesex.h

In file included from rapd.c:11:0:
ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

In file included from ars.h:20:0,
from split.c:11:
bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

error can not find the byte order for this architecture, fix bytesex.h

In file included from split.c:11:0:
ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)ENDIAN"
#error "Please, edit Makefile and add -DBYTE_ORDER(BIG|LITTLE)_ENDIAN"

now you can try `make'
root@90f655fa08f0:/hping3#

the os version is :

root@90f655fa08f0:/hping3# uname -a
Linux 90f655fa08f0 4.4.41-moby #1 SMP Wed Jan 11 01:09:58 UTC 2017 x86_64 GNU/Linux

Hai @antirez

Thank you for your contribution.

Is there any plan to add QUIC protocol support?

Looking forward for your reply.

Thank you.

tramitted? instead of 'transmitted'? Maybe its a language thing, I'm not sure but thought I would mention it anyway...

I noticed something related to hping3. Run the following command on the same machine on two different consoles:

sudo hping3 www.times.com -S -p 80

You will see a number of results with "rtt=0.0 ms" on both consoles, that they wouldn't be there if you were running only one command.

I think this is due to both processes catching each other's tcp packets. Since, they figure out they didn't send them, they print a rtt=0.0 ms.

The problem is in the function rtt() in rtt.c where it does *ms_delay = 0. Currently an hping3 process prints a 0.0 when it receives a packet that doesn't belong to it. However, I think in this case the packet should be ignored, and print nothing.

I would like to hear if there is a strong reason why it currently prints 0.0.