From owner-freebsd-current  Fri Jul 25 12:21:59 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA19490
          for current-outgoing; Fri, 25 Jul 1997 12:21:59 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19480
          for <freebsd-current@FreeBSD.ORG>; Fri, 25 Jul 1997 12:21:54 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id LAA07780;
	Fri, 25 Jul 1997 11:53:56 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd007775; Fri Jul 25 18:53:50 1997
Message-ID: <33D8F5CB.5E652F78@whistle.com>
Date: Fri, 25 Jul 1997 11:51:55 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: "Richard Seaman, Jr." <lists@tar.com>
CC: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>
Subject: Re: Whats happened to ping?
References: <199707251537.KAA28194@ns.tar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Richard Seaman, Jr. wrote:


I'm to blame..
this is a side effect of something I did

I also noticed another yesterday..
I must have coded this wromg because I thought I told it to only not
count errors that were ENOBUFS
(while in flood mode)..
I'll check and fix if needed


julian

> 
> It seems that there have recently been changes to the sematics of
> "ping -c N".  Unless I'm mistaken, the old behavior was that "ping -c N"
> meant try to send N packets.  Now it means keep trying until N packets
> are actually sent.
> 
> The practical effect of this is that "ping -c N" might loop endlessly,
> if, for example, the network is down and the sendto fails.  An actual
> example:
> 
> # ping -c 1 -n -q 204.95.160.35
> PING 204.95.160.35 (204.95.160.35): 56 data bytes
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ping: sendto: Network is down
> ^C
> --- 204.95.160.35 ping statistics ---
> 0 packets transmitted, 0 packets received,
> 
> The problem with this is that if you put "ping -c N" in a script,
> expecting it to return at some point, you can now effectively have
> your script hang.  Which, of course, is what happened to me.
> 
> While I'm sure there are good reasons for the change, I wonder:
> 
> a) If it wouldn't be a good idea to leave the "-c" option with
>    the old meaning, and have a new option for the new behaviour
> 
> b) If you don't restore the old meaning, a lot of people who
>    depend on ping to return when using the "-c" option will
>    get burned when they upgrade to current.
> 
> Now, if I'm the only one affected, I can certainly work around
> this new behaviour.  But, I wonder if there aren't others in the
> same boat.