Calculation of lost packets off-by-one about arping

[ThomasHabets]

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]

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]

$ 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]

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]

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]

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]

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]

$ 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]

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

[ThomasHabets]

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]

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

[ThomasHabets]

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