When attempting to debug a network problem, ping incorrectly reported
Experimentation showed that this was due to the new "feature" of attempting
to print the hostname on *every* line of the ping output, rather than just
the header. Now, I don't like this "feature" in general, because it causes
the ping output lines to wrap, something I immediately noticed after
upgrading from 6.1 to 6.2. I prefer the old behavior, where the hostname is
only reported on the first line of the ping output, and I can expect the
ping time at the end of the single line, rather than at the beginning of
the wrapped line, or worse yet, *split* between the two lines.
However, much more serious, it appears (I'm guessing as I haven't looked at
the code), that now ping is attempting to do a DNS lookup for *each* line
of output, rather than just once at the beginning, causing it to
erroneously report failure when that lookup fails. (Actually, it produces
*no* output, and after ctrl-c reports 1 success and n-1 failures). However,
monitoring on the other system with tcpdump showed that the pings were
actually successful. This is a change in ping behavior, and may break
scripts and established network testing and debugging procedures.
I know there is a -n option, but I have never had to use it in the past
when explicitly pinging an IP address rather than a hostname. So, I would
like to suggest that at the very least, ping should default to the -n mode
when explicitly pinging an IP address rather than a hostname (i.e. ping
xxx.xxx.xxx.xxx). I would also like to suggest that ping default to its old
behavior altogether - there should be a NEW OPTION to specify a NEW
BEHAVIOR - that you want the hostname on every line of output (though I
can't imagine why anyone would actually want that!).
This (it was not the main issue, though) has been fixed in errata iputils-20001010-1.