iputils' arping has a -w deadline option, which allows to "Specify a timeout, in seconds, before arping exits regardless of how many packets have been sent or received". In net-misc/iputils-20180629, the deadline option works (tested on amd64 and arm). E.g. for a dead host: # time arping -w 3 -f 192.168.1.10 -I br1 ARPING 192.168.1.3 from 192.168.1.10 br1 Sent 4 probes (4 broadcast(s)) Received 0 response(s) real 0m4.011s user 0m0.001s sys 0m0.000s However, starting with net-misc/iputils-20190515, arping seems to wait forever and doesn't exit. It doesn't seem to be blocked/dead. Using strace, I can see it keeps repeating the following calls every ~1 second: read(5, "\1\0\0\0\0\0\0\0", 8) = 8 clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=4537848, tv_nsec=475941894}) = 0 sendto(3, "\0\1\10\0\6\4\0\1\0\33!\20\245z\300\250\1\1\377\377\377\377\377\377\300\250\1\n", 28, 0, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ARP), sll_ifindex=if_nametoindex("br1"), sll_hatype=ARPHRD_ETHER, sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xff, 0xff, 0xff, 0xff, 0xff, 0xff]}, 20) = 28 poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}], 3, -1 The following versions are affected: net-misc/iputils-20190709-r1 (tested on amd64 and arm) net-misc/iputils-20190709 (tested on amd64 only) net-misc/iputils-20190515 (tested on amd64 only) I only noticed the issue now that net-misc/iputils-20190709-r1 was stabilised. In the mean time, I will revert my systems to version 20180629. This is probably a bug upstream, but I don't know of a more appropriate place to report it. Any help is appreciated. Thanks in advance.
Why are you using that version? Newer version is already stable... *** This bug has been marked as a duplicate of bug 692982 ***
Wait, looks like you are reporting a different issue.
Can you please test patch from https://github.com/iputils/iputils/issues/211 ?
Thanks, Thomas. I didn't know they where on GitHub. I just tried https://github.com/iputils/iputils/commit/1df5350bdc952b14901fde356b17b78c2bcd4cff.patch on amd64 with version 20190709-r1. It fixes the issue with "-w" when used with "-f": # time arping -w 3 -f 192.168.1.10 -I br1 ARPING 192.168.1.10 from 192.168.1.1 br1 Sent 3 probes (3 broadcast(s)) Received 0 response(s) real 0m3.008s user 0m0.000s sys 0m0.002s BUT "-w" on its own is still broken (only exits after Ctrl+C): # time arping -w 3 192.168.1.10 -I br1 ARPING 192.168.1.10 from 192.168.1.1 br1 ^CSent 167 probes (167 broadcast(s)) Received 0 response(s) real 2m47.010s user 0m0.002s sys 0m0.011s Should I report this on GitHub?
Yes please. Maybe try our live ebuild first to check if it's still broken in upstream's repository.
I just tried the live ebuild on amd64 and it seems to be fixed upstream already, so no need for a report upstream. repository: https://github.com/iputils/iputils.git at the commit: 74790fd2128aac88796e9fe5cb28787e97902044 # time arping -w 3 -f 192.168.1.10 -I br1 ARPING 192.168.1.10 from 192.168.1.1 br1 Sent 4 probes (4 broadcast(s)) Received 0 response(s) real 0m3.011s user 0m0.000s sys 0m0.002s # time arping -w 3 192.168.1.10 -I br1 ARPING 192.168.1.10 from 192.168.1.1 br1 Sent 4 probes (4 broadcast(s)) Received 0 response(s) real 0m3.007s user 0m0.000s sys 0m0.002s I also discovered this issue upstream which is exactly what I reported: https://github.com/iputils/iputils/issues/259 If you want to release a new ebuild revision to 20190709, the patches necessary to fix the issue (which I also tested) are: # cd /etc/portage/patches/net-misc/iputils-20190709-r1 && ls | cat 0001-1df5350bdc952b14901fde356b17b78c2bcd4cff.patch 0002-ec821e572a640bd79aecc3922cb9001f4b6b26f2.patch 0003-e594ca52afde89746b7d79c875fe9d6aea1850ac.patch 18f14be80466ddc8fb17a400be82764a779c8dcd is also needed and is already applied to 20190709-r1
Should be fixed with iputils-20200821.
Just tested on amd64/arm and it works. Thanks!
