Bug 40068 - multiple bugs in ping from iputils-20001110
multiple bugs in ping from iputils-20001110
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: iputils (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-10 08:50 EDT by Need Real Name
Modified: 2015-03-04 20:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-10 09:15:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

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

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 (216.148.218.195) from 196.30.193.232 : 56(84) bytes of
data.
64 bytes from 216.148.218.195: 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 (216.148.218.195) from 196.30.193.232 : 56(84) bytes of
data.
 
--- 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 09:15:19 EDT
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
             expires.

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 09:52:11 EDT
{ 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
iputils-20001110-1

[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
PM SAST
Install date: Thu 10 May 2001 11:56:36 AM SAST      Build Host:
porky.devel.redhat.com
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:
DESCRIPTION
     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:
{snip}
 -c count
             Stop after sending count ECHO_REQUEST packets. With deadline op-
             tion, ping waits for count ECHO_REPLY packets, until the timeout
             expires.
{snip}

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
this.
Comment 3 Need Real Name 2001-05-10 10:07:37 EDT
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!

--Craig

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