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).
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
{ 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.
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