5

I have compared two tools for the speed of sending packets, hping and packETHcli. The command line options for packETHcli is 

./packETHcli -i eth0 -m 2 -n 0 -d -1 -f icmpSample.pcap

and for hping is 

hping --flood 192.168.0.1

But in iptraf, it shows that the packets sending speed of hping is about 10 times faster than packETHcli.

Both tools use raw sockets, but why such a big difference?

Here is the link to get the source codes.

hping: http://wiki.hping.org/

packETHcli: http://sourceforge.net/projects/packeth/

EDIT: I noticed that the hping use AF_INET raw socket, the payload is TCP. packETHcli use PF_PACKET raw socket, and in my example the payload is and IP packet with payload of ICMP. Do it make the difference of the packet sending speed ?

EDIT2

This time,I use ifconfig to find the TX packets count difference between before and after running hping3 and packETHcli. And found that the packets generating rates are close for the two tools. hping3 is about 100000 packets per seconds and packETHcli is about 80000 packets per seconds.

I also use vnstat to measure the packets generating rates. And the result is consistent with the number I get from ifconfig.

So, it seems that iptraf lies. And I use iptraf to monitor the repeated resending of a TCP packet, without update the IP ID number and TCP sequence number. iptraf think my packet sending rate is 0 packets per seconds. May be iptraf don't count the duplicated packets?

longbowk
  • 219
  • 5
  • 14
  • 1
    Are they both maxing out on CPU usage? Perhaps one is more efficiently coded than the other. (As a specialized tool, hping is probably leaner). – nneonneo Mar 01 '13 at 02:49
  • @nneonneo They both use sendto() to send the raw packet, and wrapped in a for(;;) or while(1) loop. Both run in single thread. – longbowk Mar 01 '13 at 03:53
  • Mhm, but how much other crud is there in that loop? All I'm asking is to do a `top` comparison of CPU usage to see if they are both maxing out the CPU. You may also want to see if they are maxing out the network with `ntop`. – nneonneo Mar 01 '13 at 03:59
  • @nneonneo The CPU utilization of `packETHcli` is about 19% and `hping3` is 100%. `hping3` build the packet manually in userspace, then send it through sendto(2) and it repeats this process in each loop of while(1). And `packETHcli` just call sendto(2) with same packet data in the loop of for(;;), the packet data is read from icmpSample.pcap file at program startup once, not repeats in the loop. – longbowk Mar 01 '13 at 09:08
  • 1
    So that must mean that `packETHcli` is blocking a lot. I wonder if `hping3` uses any non-blocking options for the socket. (You may use `strace` if you want to know exactly how the sockets are being configured). – nneonneo Mar 01 '13 at 09:14
  • In the example `packETHcli` reads a .pcap from the disk. No wonder it is slower than generating data in memory. It also explains the blocking. – thuovila Mar 01 '13 at 10:52
  • @thuovila It is not the problem, it only read the packet data once, and use it in the loop repeatedly. So it's not blocked on the disk I/O. – longbowk Mar 01 '13 at 14:33
  • @nneonneo ,@thuovila, Thanks for your advice. I updated my question, added my latest testing result. And I think I found the answer. Let me know your comments. – longbowk Mar 01 '13 at 14:48

1 Answers1

0

There is timestamp information for each packet in the *.pcap file. And I think the tool packETHcli is parsing the *.pcap file, using the timestamp information to simulate the network environment where the *.pcap file is captured, that means it has to add some delay between packets according to the timestamp.

While hping does not.

I think that's the difference.

If so, is there any option in the packETHcli tool which supports to speed up the packets sending?

tian_yufeng
  • 1,780
  • 10
  • 8