14.04, arping, time to wait option

[Max]

Ubuntu 14.04.1 LTS

arping from 'arping' package(not iputils-arping) version 2.11

example shows the problem:

# arping 192.168.10.120 -c 10 -w 100000
ARPING 192.168.10.120

--- 192.168.10.120 statistics ---
10 packets transmitted, 0 packets received, 100% unanswered (0 extra)

so, 100% loss.

The same syntax is working with Ubuntu 12.04.1 LTS and arping version 2.09.

[Thomas Habets (p-thomas-8)]

This is probably the known issue that was fixed in upstream in Aug 2012, over two years ago.

Try again with arping-2.13 or later.

[Max (evpamex)]

Hello,

Thank you for your replay.
Version 2.14 solved the above problem.

But now I have new issue. Look at replay delay:

./arping 192.168.10.120 -c 5
ARPING 192.168.10.120
60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=0 time=130.299 msec
60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=1 time=129.696 msec
60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=2 time=129.545 msec
60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=3 time=224.335 msec
60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=4 time=465.971 msec

and now output by arping (from iputils-arping package) on the same station:

arping -I eth0 -c 5 192.168.10.120
ARPING 192.168.10.120 from 192.168.10.131 eth0
Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.553ms
Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.598ms
Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.598ms
Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.556ms
Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.555ms

Why so big difference in reply delay?
Output from arping (iputils-arping) looks like more accurate about delay value.

2014-12-03 13:16 GMT+04:00 Thomas Habets <email address hidden>:
> This is probably the known issue that was fixed in upstream in Aug 2012,
> over two years ago.
>
> Try again with arping-2.13 or later.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398467
>
> Title:
> 14.04, arping, time to wait option
>
> Status in arping package in Ubuntu:
> New
>
> Bug description:
> Ubuntu 14.04.1 LTS
>
> arping from 'arping' package(not iputils-arping) version 2.11
>
>
> example shows the problem:
>
>
> # arping 192.168.10.120 -c 10 -w 100000
> ARPING 192.168.10.120
>
> --- 192.168.10.120 statistics ---
> 10 packets transmitted, 0 packets received, 100% unanswered (0 extra)
>
>
> so, 100% loss.
>
> The same syntax is working with Ubuntu 12.04.1 LTS and arping version
> 2.09.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/arping/+bug/1398467/+subscriptions

[Thomas Habets (p-thomas-8)]

That's a completely different issue and is actually a regression in
libpcap somewhere between 1.3 and 1.6.2. I have a TODO to investigate
if this is a known issue, or if I can just send a patch.

iputils-arping, if I remember correctly, doesn't use libpcap but
instead Linux-specific API calls, which is why it would be unaffected.

On 4 December 2014 at 12:24, Max <email address hidden> wrote:
> Hello,
>
> Thank you for your replay.
> Version 2.14 solved the above problem.
>
> But now I have new issue. Look at replay delay:
>
> ./arping 192.168.10.120 -c 5
> ARPING 192.168.10.120
> 60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=0 time=130.299 msec
> 60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=1 time=129.696 msec
> 60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=2 time=129.545 msec
> 60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=3 time=224.335 msec
> 60 bytes from 00:30:4f:61:4e:13 (192.168.10.120): index=4 time=465.971 msec
>
>
> and now output by arping (from iputils-arping package) on the same station:
>
> arping -I eth0 -c 5 192.168.10.120
> ARPING 192.168.10.120 from 192.168.10.131 eth0
> Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.553ms
> Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.598ms
> Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.598ms
> Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.556ms
> Unicast reply from 192.168.10.120 [00:30:4F:61:4E:13] 0.555ms
>
>
> Why so big difference in reply delay?
> Output from arping (iputils-arping) looks like more accurate about delay value.
>
> 2014-12-03 13:16 GMT+04:00 Thomas Habets <email address hidden>:
>> This is probably the known issue that was fixed in upstream in Aug 2012,
>> over two years ago.
>>
>> Try again with arping-2.13 or later.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1398467
>>
>> Title:
>> 14.04, arping, time to wait option
>>
>> Status in arping package in Ubuntu:
>> New
>>
>> Bug description:
>> Ubuntu 14.04.1 LTS
>>
>> arping from 'arping' package(not iputils-arping) version 2.11
>>
>>
>> example shows the problem:
>>
>>
>> # arping 192.168.10.120 -c 10 -w 100000
>> ARPING 192.168.10.120
>>
>> --- 192.168.10.120 statistics ---
>> 10 packets transmitted, 0 packets received, 100% unanswered (0 extra)
>>
>>
>> so, 100% loss.
>>
>> The same syntax is working with Ubuntu 12.04.1 LTS and arping version
>> 2.09.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ubuntu/+source/arping/+bug/1398467/+subscriptions

--
typedef struct me_s {
 char name[] = { "Thomas Habets" };
 char email[] = { "<email address hidden>" };
 char kernel[] = { "Linux" };
 char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" };
 char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

[Thomas Habets (p-thomas-8)]

The bug this page is about is fixed in arping-2.13, and Ubuntu should update to at least that version.

The delay issue is now fixed in upstream and will be part of arping-2.15. It was not a bug in libpcap, but an API change that meant buffering delays were introduced by default.