Description
Forwarded from Debian bug 456191, which has been open for ages.
From the original request,
> thule:~# ping -w 120 -c 1 thule-3
> PING thule-3 (***.37.54) 56(84) bytes of data.
> From thule.uk.xensource.com (***.33.107) icmp_seq=1 Destination Host Unreachable
> From thule.uk.xensource.com (***.33.107) icmp_seq=2 Destination Host Unreachable
> From thule.uk.xensource.com (***.33.107) icmp_seq=3 Destination Host Unreachable
>
> --- thule-3 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms
> , pipe 3
> thule:~# echo $?
> 1
> thule:~#
>
> This is a less than helpful behaviour, particularly with modern
> kernels which send host unreachable when the host is not replying to
> arp. It makes -w useless in most of the situations where you might
> want it.
This behavior is still present, but I'm at a loss to explain why, and in particular why it's implied when the -w flag is used, as seen in ping_common.c:
if (rts->deadline && rts->nerrors)
break;
The behavior has been present since at least version 20020124 (from 2002, the oldest version present in the Debian historical archives). However, the Debian bug report suggests that the kernel behavior may have changed since the ping behavior was introduced ("particularly with modern kernels which send host unreachable when the host is not replying to arp"), so it's not clear that the current ping behavior was intended when the code was written.
In any case, since the current behavior has been in place for so long, I'm not entirely comfortable changing the default. My inclination is to add a new command-line switch to tell ping to ignore errors when running with a deadline.