search

ThomasHabets / arping

ARP Ping
http://www.habets.pp.se/synscan/programs.php
GNU General Public License v2.0
403 stars 63 forks source link

Calculation of lost packets off-by-one #1

Closed dlorch closed 14 years ago

dlorch commented 14 years ago

The calculation of the number of lost packets is off by one. Here's a demonstration:

$ sudo arping -i en1 192.168.1.1
ARPING 192.168.1.1
^C
--- 192.168.1.1 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)

What happens here is that I quit ARPing before it could receive the last response 'out in the air'. The calculation error is actually quite significant, as even for 1 packet out of 10, ARPing would show a 10% loss that actually isn't there.

For the calculation of the unanswered packets, ARPing shouldn't account for the last packet that is out in the air.

I am using ARPing 2.09 on OSX (via MacPorts).

Thank you in advance for considering this ticket.

ThomasHabets commented 14 years ago

How fast are you pressing ^C?

How slow is the network?

What happens when you run "arping -c 1 -i en1 192.168.1.1"?

I'm unable to reproduce the problem on my Debian box using arping-2.09. I don't have access to OSX.

$ sudo ./src/arping 172.21.0.1
ARPING 172.21.0.1
42 bytes from 4a:cb:ab:0a:f8:13 (172.21.0.1): index=0 time=1.653 msec
^C
--- 172.21.0.1 statistics ---  
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)

$ sudo ./src/arping -c 1 172.21.0.1
ARPING 172.21.0.1
42 bytes from 4a:cb:ab:0a:f8:13 (172.21.0.1): index=0 time=828.028 usec
^C
--- 172.21.0.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)
dlorch commented 14 years ago

It's WLAN (802.11g). It doesn't really matter how fast I press ^C, the problem consistently appears no matter how short or long I let ARPing run.

Would you like to get an SSH access to my machine? Maybe it's a particularity of OSX.

dlorch commented 14 years ago 
$ sudo arping -c 1 -i en1 192.168.1.1
ARPING 192.168.1.1

--- 192.168.1.1 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Hmm that's weird! There doesn't appear to be anything particular in macports either (except for a patch for libpcap): http://svn.macports.org/repository/macports/trunk/dports/net/arping/

dlorch commented 14 years ago

Here with increased verbosity:

$ sudo arping -vvv -c 1 -i en1 192.168.1.1
libnet_init(en1)
libnet_init(en1)
pcap_get_selectable(): 4
This box:   Interface: en1  IP: 192.168.1.34   MAC address: 00:1e:c2:bc:3f:d0
ARPING 192.168.1.1
arping: sending packet at time 1283781409 963891
arping: received response for ip ping

--- 192.168.1.1 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)
dlorch commented 14 years ago

Now this is reaaaallly odd. Seems to be a timing problem. Here a gdb session, first just running normally, second time with a breakpoint on pingip_recv. I'm not doing anything except for pausing the application, but the results are completely different:

$ sudo gdb /opt/local/bin/arping
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar  5 04:43:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done

(gdb) r -c 1 -i en1 192.168.1.1
Starting program: /opt/local/bin/arping -c 1 -i en1 192.168.1.1
Reading symbols for shared libraries +++. done
ARPING 192.168.1.1

--- 192.168.1.1 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Program exited with code 01.
(gdb) b pingip_recv
Breakpoint 1 at 0x100002f2f
(gdb) r -c 1 -i en1 192.168.1.1
Starting program: /opt/local/bin/arping -c 1 -i en1 192.168.1.1
ARPING 192.168.1.1

Breakpoint 1, 0x0000000100002f2f in pingip_recv ()
(gdb) c
Continuing.

Breakpoint 1, 0x0000000100002f2f in pingip_recv ()
(gdb) c
Continuing.
42 bytes from 40:4a:03:03:0a:d8 (192.168.1.1): index=0 time=2.685 sec

--- 192.168.1.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)

Program exited normally.
(gdb)
dlorch commented 14 years ago

I must imagine that this is a bug in libpcap. Maybe the packet is stuck in a buffer and the buffer needs to be 'flushed' to the application.

ThomasHabets commented 14 years ago

Strange.

"received response for ip ping" means basically that there was an ARP packet on the network. All arping does after that is check that it's a reply to what it actually sent and prints that. So that message can be seen without the real packet actually having arrived.

Delays or buffers in pcap sounds strange too. On the other hand I've heard strange things about OSX.

I can take a look on your OSX box, but I would need root to both tcpdump and run arping (and modified versions of arping outputting more stuff).

What happens if you run with -c 1 -w 10000000 ?

dlorch commented 14 years ago 
$ sudo arping -c 1 -w 10000000 -i en1 192.168.1.1
ARPING 192.168.1.1

--- 192.168.1.1 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered (0 extra)
dlorch commented 14 years ago

I've sent you an SSH login via private github messageing.

ThomasHabets commented 14 years ago

It seems that poll() doesn't work against the libpcap file descriptor. Works fine with select() though.

I have left arping-2.09-plus-patch and arping-next-version in my home directory on your machine.

Could you check if this fixes it (i.e. both binaries work fine)?

(the next-version one automatically finds the interface to use, so no need for -i en1)

dlorch commented 14 years ago

Both version work fine, thank you very very much for the fix!

ThomasHabets commented 14 years ago

The commit that fixed it: http://github.com/ThomasHabets/arping/commit/b0a754550bb873b4fdb7049bfc394d38bfe3c72b