![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
muwlgrhping (hping3) is a well-known open-source ping enhancement. However now the project looks like abandoned (last release was in Nov.2005), and more importantly, it does not look like it was ever tested outside of single-user&single-session mode. I tried to use it in Cacti monitoring scripts as a convenient command-line TCP/SYN ping tool with RTT measurement, and stumbled on an unpleasant bug : in hping output, RTT times were often measured as 0.0 ms instead of actual truth-resembling times, which spoiled my graphs undeservedly.
After spending certain time on studying hping sources, I noticed some logic flaws that were harmless in single-task using of hping but caused bugs in its multi-tasking.
First, in main.c, random number generator is seeded (srand) with the value of time(0) function, and then rand() value is used to determine source port. So if multiple hping processes are started within the same second on the same host, they can generate equal and thus colliding port numbers. My quick and dirty fix was to add getpid() value to srand() seed, to give it some perturbation in multi-task hping start.
Next, probe packets sent by hping are recorded in a circular array together with their timestamps. This array is used to measure RTT and to detect possible duplicate replies. The search function, rtt(), returns integer values S_SENT or S_RECV if matching packet record is found, and 0 if it is not found. Unfortunately, S_SENT is defined as 0 in the hping header file so it is impossible to distinguish valid and error returns from rtt(). My quick fix was to alter S_SENT value to be non-zero. As well, I added a return condition in recv_tcp() function to handle unmatched tcp replies properly.
Now, I hope, my Cacti graphs obtained from hping will be impecccable :>
The whole discussion in Russian, together with resulting patch, can be seen at http://groups.google.com/group/ukr.nodes/browse_thread/thread/741fc51e58a97b4c
After spending certain time on studying hping sources, I noticed some logic flaws that were harmless in single-task using of hping but caused bugs in its multi-tasking.
First, in main.c, random number generator is seeded (srand) with the value of time(0) function, and then rand() value is used to determine source port. So if multiple hping processes are started within the same second on the same host, they can generate equal and thus colliding port numbers. My quick and dirty fix was to add getpid() value to srand() seed, to give it some perturbation in multi-task hping start.
Next, probe packets sent by hping are recorded in a circular array together with their timestamps. This array is used to measure RTT and to detect possible duplicate replies. The search function, rtt(), returns integer values S_SENT or S_RECV if matching packet record is found, and 0 if it is not found. Unfortunately, S_SENT is defined as 0 in the hping header file so it is impossible to distinguish valid and error returns from rtt(). My quick fix was to alter S_SENT value to be non-zero. As well, I added a return condition in recv_tcp() function to handle unmatched tcp replies properly.
Now, I hope, my Cacti graphs obtained from hping will be impecccable :>
The whole discussion in Russian, together with resulting patch, can be seen at http://groups.google.com/group/ukr.nodes/browse_thread/thread/741fc51e58a97b4c
