nping appears to miss or drop a packet when run with newer kernel/libraries

[Paul Blankenbaker <paul.blankenbaker () redali com>]

We are running into a issue with the nping command when run as the
root user (where ICMP packets are used by default). The 6.40 release
of the nping command seems to run as expected for us when run on
Fedora 18 based systems, but seems to miss a packet when run on Fedora
20 based systems when invoked in the following manner:

sudo nping 192.168.1.2

We are curious if anyone else has run into a similar issue with the
nping utility and if they have found a work around (we could not seem
to remedy the problem by adjusting the delay as that only seemed to
adjust the delay between subsequent "pings").

The following is an example of the output from nping on the problem
systems (the first RCVD packet appears to have been missed).

[devel@taco-dev64 dev]$ sudo nping 192.168.1.2

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2014-01-12 07:23 EST
SENT (0.0168s) ICMP [192.168.1.45 > 192.168.1.2 Echo request
(type=8/code=0) id=51556 seq=1] IP [ttl=64 id=10991 iplen=28 ]
SENT (1.0240s) ICMP [192.168.1.45 > 192.168.1.2 Echo request
(type=8/code=0) id=51556 seq=2] IP [ttl=64 id=10991 iplen=28 ]
RCVD (1.0251s) ICMP [192.168.1.2 > 192.168.1.45 Echo reply (type=0/code=0)
id=51556 seq=1] IP [ttl=64 id=33489 iplen=28 ]
SENT (2.0323s) ICMP [192.168.1.45 > 192.168.1.2 Echo request
(type=8/code=0) id=51556 seq=3] IP [ttl=64 id=10991 iplen=28 ]
RCVD (2.0333s) ICMP [192.168.1.2 > 192.168.1.45 Echo reply (type=0/code=0)
id=51556 seq=2] IP [ttl=64 id=33490 iplen=28 ]
SENT (3.0351s) ICMP [192.168.1.45 > 192.168.1.2 Echo request
(type=8/code=0) id=51556 seq=4] IP [ttl=64 id=10991 iplen=28 ]
RCVD (3.0379s) ICMP [192.168.1.2 > 192.168.1.45 Echo reply (type=0/code=0)
id=51556 seq=3] IP [ttl=64 id=33491 iplen=28 ]
SENT (4.0409s) ICMP [192.168.1.45 > 192.168.1.2 Echo request
(type=8/code=0) id=51556 seq=5] IP [ttl=64 id=10991 iplen=28 ]
RCVD (4.0418s) ICMP [192.168.1.2 > 192.168.1.45 Echo reply (type=0/code=0)
id=51556 seq=4] IP [ttl=64 id=33492 iplen=28 ]

Max rtt: 0.600ms | Min rtt: 0.349ms | Avg rtt: 0.460ms
Raw packets sent: 5 (140B) | Rcvd: 4 (184B) | Lost: 1 (20.00%)
Nping done: 1 IP address pinged in 4.06 seconds
[devel@taco-dev64 dev]$


In this situation, the nping command appears to have missed the first
ICMP packet returned. We ran dumpcap to capture the packets on the
wire to see what was going on while the nping command was running. It
did appear that nping put out 5 ICMP requests and that 5 ICMP replies
came back from the target system (shown below). The first reply was
roughly 0.5 milliseconds after the request (not sure if this short
duration is meaningful or not).

[devel@taco-dev64 dev]$ tcpdump -r ~/Downloads/capture_p2p1.cap
reading from file /home/devel/Downloads/capture_p2p1.cap, link-type EN10MB
(Ethernet)
07:23:25.340951 IP taco-dev64.linux.bogus > rice.linux.bogus: ICMP echo
request, id 51556, seq 1, length 8
07:23:25.341459 IP rice.linux.bogus > taco-dev64.linux.bogus: ICMP echo
reply, id 51556, seq 1, length 8
07:23:26.348309 IP taco-dev64.linux.bogus > rice.linux.bogus: ICMP echo
request, id 51556, seq 2, length 8
07:23:26.348908 IP rice.linux.bogus > taco-dev64.linux.bogus: ICMP echo
reply, id 51556, seq 2, length 8
07:23:27.356727 IP taco-dev64.linux.bogus > rice.linux.bogus: ICMP echo
request, id 51556, seq 3, length 8
07:23:27.357264 IP rice.linux.bogus > taco-dev64.linux.bogus: ICMP echo
reply, id 51556, seq 3, length 8
07:23:28.359328 IP taco-dev64.linux.bogus > rice.linux.bogus: ICMP echo
request, id 51556, seq 4, length 8
07:23:28.361343 IP rice.linux.bogus > taco-dev64.linux.bogus: ICMP echo
reply, id 51556, seq 4, length 8
07:23:29.365133 IP taco-dev64.linux.bogus > rice.linux.bogus: ICMP echo
request, id 51556, seq 5, length 8
07:23:29.365653 IP rice.linux.bogus > taco-dev64.linux.bogus: ICMP echo
reply, id 51556, seq 5, length 8
[devel@taco-dev64 dev]$

I'm not sure as to why nping missed the first packet. Here are some
combinations which I've tried that exhibit the issue:

On Fedora 20 (kernel: 3.12.6-300.fc20.x86_64), wheter I use Fedora's
version of nmap or build nmap from source, the nping utility seems to
always miss a packet. Here is the output of "nping -version" and "nmap
-version" which shows the libraries linked in.

Nping version 0.6.40 ( http://nmap.org/nping )

Nmap version 6.40 ( http://nmap.org )
Platform: x86_64-redhat-linux-gnu
Compiled with: liblua-5.2.2 openssl-1.0.1e libpcre-8.33 libpcap-1.5.0
nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select


I do not see the issue on Fedora 18 (kernel: 3.11.10-100.fc18.i686) I
do not see nping dropping any packets. Here is some of the version
information I see on this system.

Nping version 0.6.40 ( http://nmap.org/nping )

Nmap version 6.40 ( http://nmap.org )
Platform: i686-redhat-linux-gnu
Compiled with: nmap-liblua-5.2.2 openssl-1.0.1e libpcre-8.31 libpcap-1.3.0
nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select


Since the nping command is the same version on the two systems, I'm at
a loss to explain why the behavior is different (unless it has
something to do with the newer kernel, libpcre library or libpcap
library). Is it possible that a bug in the nping utility has presented
itself due to the newer version of the libraries/kernel?

In any case, if anyone would have some suggestions on what to do to
avoid this issue I would appreciate it (it's quite possible I'm just
being stupid and missing something obvious - if so I apologize). I can
provide more information and/or packet captures if necessary.

Thanks,
Paul
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/