Bug 40068 - multiple bugs in ping from iputils-20001110
Summary: multiple bugs in ping from iputils-20001110
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: iputils
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-10 12:50 UTC by Need Real Name
Modified: 2015-03-05 01:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2001-05-10 13:15:25 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-05-10 12:50:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-pre1 i686; en-US; rv:0.9)

Description of problem:
Several options to ping fail to operate as the man page specifies.
The -c option does not wait to receive count echo response packets
as the man page specifies. The -w option when used with -c seems to
result in extra packets being sent. I also had a script in which the ping
return codes seemed dodgy versus what the man page said but I'll have to
investigate that a bit more.

How reproducible:
Didn't try

Steps to Reproduce:
1.Let's use the -c option and see if the program waits until it has
received all the packets as the man page says: "Stop after sending (and
receiving) count ECHO_RESPONSE packets."
2. ping -c 10 www.redhat.com
3. See actual results below. The program exits even though it hasn't
received all the packets. Actually I don't mind the behaviour but the man
page is wrong.

4. Lets use -c in combination with -w. -w _used_ to specify the wait on a
per packet basis IIRC but now it seems to specify the total wait time.We
try pinging with 10 packets and will wait up to 20 seconds.
5. time ping -n -q -c 10 -w 20 www.redhat.com

6. The results below show more than 10 packets being sent. WRONG!

Actual Results:  Results for step 3:
[craig@cnote craig]$ ping -c 10 www.redhat.com
PING www.redhat.com ( from : 56(84) bytes of
64 bytes from icmp_seq=0 ttl=48 time=1.356 sec

--- www.redhat.com ping statistics ---
10 packets transmitted, 2 packets received, 80% packet loss

Note that the program exited even though it hadn't received 10 packets.
Behaviour acceptable but the man page is wrong. How long is it supposed to
wait before giving up btw.? That should be in the man page too.

Results for step 5:
[craig@cnote craig]$ time ping -n -q -c 10 -w 20 www.redhat.com
PING www.redhat.com ( from : 56(84) bytes of
--- www.redhat.com ping statistics ---
12 packets transmitted, 10 packets received, 16% packet loss
round-trip min/avg/max/mdev = 1828.707/2596.818/3804.252/572.669 ms
real    0m11.619s
user    0m0.000s
sys     0m0.020s

Hmmm ... OK - it didn't run for a full 20 seconds, probably because it got
10 packets back but it sent 12 packets!! It was only supposed to send 10.

Expected Results:  For step 3: The result is ok. The '(and receiving)' in
the man page for the -c option should be dropped and the page should
specify how long ping will wait before deciding it isn't going to get any
more packets. The old -w behaviour (IIRC) allowed you to specify the wait
per packet rather than the total wait. That would be nice to have back
(unless I'm confusing it with window's ping which does that I think).

For step 5: It should have sent 10 packets, not 12.

Additional info:

My box is a bit of a hybrid between redhat 7.0 and 7.1. Shouldn't
make any difference though - I have the 7.1iputils package. I haven't
managed to recompile the package on my machine (seems to get screwed
up by oldish kernel headers ... need to investigate that).

Comment 1 Phil Knirsch 2001-05-10 13:15:19 UTC
Hi Craig.

I just took a brief look at your reported problems.

I've just checked with the 7.1 version there the manpage explicitly talks about
-c only accouting for sending packages:

     -c count
             Stop after sending count ECHO_REQUEST packets. With deadline op-
             tion, ping waits for count ECHO_REPLY packets, until the timeout

So i am a little puzzled here as i can't 'reproduce' the things you stated.

If you could verify again with rpm -qi iputils which version you have and maybe
send me the ping manpage or do a rpm -qf /usr/share/man/man8/ping.8.gz

Read ya, Phil

Comment 2 Need Real Name 2001-05-10 13:52:11 UTC
{ Thanks for the quick reply! }

Interesting! That's different to what my man page says but I have the right
package (well ... more on that later) ...

[craig@cnote webmonitor]$ rpm -qf /usr/share/man/man8/ping.8.gz

[craig@cnote webmonitor]$ rpm -qi iputils
Name        : iputils                      Relocations: /usr
Version     : 20001110                          Vendor: Red Hat, Inc.
Release     : 1                             Build Date: Tue 16 Jan 2001 05:34:23
Install date: Thu 10 May 2001 11:56:36 AM SAST      Build Host:
Group       : System Environment/Daemons    Source RPM: iputils-20001110-1.src.rpm
Size        : 137254                           License: BSD
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : The ping program for checking to see if network hosts are alive.
Description :
The iputils package contains ping, a basic networking tool.  The ping
command sends a series of ICMP protocol ECHO_REQUEST packets to a
specified network host and can tell you if that machine is alive and
receiving network traffic.

[craig@cnote webmonitor]$ rpm --verify iputils
[craig@cnote webmonitor]$

Seems to be the right version. I did have rpm core dump on me while upgrading
the package (perhaps because I mv'ed the rpm file while it was busy from another
session) but I re-ran the rpm command (-Uvh) and it succeeded so I assumed that
I was running the 7.1 ping rather than 7.0.

Here's a snippet from the man page:
     Ping uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit
     an ICMP ECHO_RESPONSE from a host or gateway.  ECHO_REQUEST datagrams
     (``pings'') have an IP and ICMP header, followed by a ``struct timeval''
     and then an arbitrary number of ``pad'' bytes used to fill out the pack-
     et.  The options are as follows: Other options are:
     -b      Allow pinging a broadcast address.
     -c count
             Stop after sending (and receiving) count ECHO_RESPONSE packets.

{end snippet}

Perhaps all is not well in rpm land - that is the 7.0 page methinks.
Lemme force things:

[root@cnote RPMS]# rpm -ivh --force iputils-20001110-1.i386.rpm
Preparing...                ########################################### [100%]
   1:iputils                ########################################### [100%]

Hmmm ... the man page still shows the old stuff but zless'ing the ping.gz man
file shows the right text. Perhaps man has cached the old page in some fashion
... Upgrading man to the 7.1 version ... {pause} ...

man ping:
 -c count
             Stop after sending count ECHO_REQUEST packets. With deadline op-
             tion, ping waits for count ECHO_REPLY packets, until the timeout

Better! OK. That's the first bit of the problem solved. Thanks!

It also clarifies the second bit in that it can send more than 10 packets.

Magic. Thank you! Sorry for not doing more exhaustive checking before reporting

Comment 3 Need Real Name 2001-05-10 14:07:37 UTC
Final note.

The new man page also clarifies the return code stuff I mentioned. I was
only seeing error codes of 1 and 0 but expecting code 2 when only some packets
were dropped (the old man page seemed to indicate this and it wasn't happening).
The 'new' man page clarifies that with both -w and -c I'll get a return
code of 1, not 2 in that case.

Thanks again!


Note You need to log in before you can comment on or make changes to this bug.