Bug 4668

Summary: but in -c switch
Product: [Retired] Red Hat Linux Reporter: stano
Component: netkit-baseAssignee: Jeff Johnson <jbj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 6.0CC: bertil
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-01-27 19:00:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description stano 1999-08-23 13:46:52 UTC
In 0.10.31is the bug in -c switch

 In 0.10.29 and older, -c 3 run as:
  send 3 packets, and make result of packet which are
returned.

 In 0.10.31 -c 3 run as:
   send 3 or more packets and wait for 3 returned packets,
if they doen got 3 returned packet, stay in memory and wait
for long time. I use ping in script, after weekend my system
was down, they doen have any free position for new proces in
memory, ll are used.

Comment 1 Jeff Johnson 1999-08-23 22:17:59 UTC
The "-c count" option to ping is fixed in netkit-base-0.10-35 in
Raw Hide. There's also another option "-w secs" to terminate after
<secs> seconds.

Comment 2 stano 1999-08-30 10:14:59 UTC
Hi. I try a ping from netkit-base-0.10-35
>
>    -c switch have the same bug
>    -w switch run as -i switch, don't terminate ping after secs,
>
> I try it at a
>    ping -c 1 -w 10 www.microsoft.com
>
> After 25 secs, I pres Ctrl-C, and reults was:
>
>  3 packets transmitted, 0 packets received, 100% packet loss
>
>
> !!!!!!!!!
>
>  -c 1 doesn't work, ping send 3 packets
>  -w 10 doesn't work, ping wait between sending ICMP packets 10
seconds,
>     it doesn't terminate ping
>
>   Plese repair it, thanx

Comment 3 Jeff Johnson 1999-09-04 21:50:59 UTC
Both -c and -w work for me (note bogus 1.2.3.4 address):

krusty:/J/netkit-base 532 bash$ /bin/ping -w 2 1.2.3.4

PING 1.2.3.4 (1.2.3.4) from 207.175.42.132 : 56(84) bytes of data.
From Loopback0.GW2.RDU1.ALTER.NET (137.39.3.252): Destination Host
Unreachable

--- 1.2.3.4 ping statistics ---
1 packets transmitted, 0 packets received, +1 errors, 100% packet loss
krusty:/J/netkit-base 533 bash$ /bin/ping -c 2 1.2.3.4
PING 1.2.3.4 (1.2.3.4) from 207.175.42.132 : 56(84) bytes of data.
From Loopback0.GW2.RDU1.ALTER.NET (137.39.3.252): Destination Host
Unreachable
From Loopback0.GW2.RDU1.ALTER.NET (137.39.3.252): Destination Host
Unreachable

--- 1.2.3.4 ping statistics ---
2 packets transmitted, 0 packets received, +2 errors, 100% packet loss
krusty:/J/netkit-base 534 bash$ rpm -qf /bin/ping
netkit-base-0.10-36

(the 0.10-36 ping is identical to the 0.10-35 ping)

The -w has changed meaning in the Kuznetsov ping. If your ping
interpreted the -w as the wait time between packets, then you
appear to not be running the 0.10-3[56] ping.

Comment 4 Jeff Johnson 1999-09-04 21:52:59 UTC
*** Bug 4884 has been marked as a duplicate of this bug. ***

ping -c 1 host does not timeout. It sends off packets after
the first packet. When the host doesn't respond to the only
packet I asked ping to send, ping should timeout and
respond that host is not available.

------- Additional Comments From dkl  09/03/99 13:42 -------
What version of netkit-base are you using? The machine that i used to
verigy this problem has netkit-base-0.10-35 which doesnt seem to have
this problem. If you want to try this newer version it can be obtained
at:

ftp://ftp.redhat.com/rawhide/i386/rawhide/RedHat/RPMS/netkit-base-0.10-35.i386.rpm

The problem may have been fixed in this newer package.

Comment 5 stano 1999-09-13 07:56:59 UTC
Hi. OK. Why the -w doesn't work aka: stop pinging after 10 seconds?
and -c switch doesn't work...

  You write that you use ping -c 2 1.2.3.4, yes you are right, ping
write that destination unreachable, but try to use

  ping -c 2 www.microsoft.com

I use netkit-base-0.10-35

stano

Comment 6 James Manning 2000-01-19 21:48:59 UTC
Can this be opened back up?
As per my cartman-list post today, I believe it was just
hard/impossible to reproduce at redhat.com due to well-behaved
routers getting back ICMP errors quickly enough, and that the
ping code is genuinely broken as per previous complaints.

If requested, I'll paste my cartman-list findings here.

Comment 7 Jeff Johnson 2000-01-27 19:00:59 UTC
This problem should be resolved in the iputils-991024-1 package from
Raw Hide.