From owner-freebsd-net@FreeBSD.ORG Wed Sep 17 15:33:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E2ACD0; Wed, 17 Sep 2014 15:33:39 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 780C5D32; Wed, 17 Sep 2014 15:33:39 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 143891) id C47D14E02; Wed, 17 Sep 2014 17:33:25 +0200 (SAST) Date: Wed, 17 Sep 2014 17:33:25 +0200 From: John Hay To: freebsd-net@freebsd.org Subject: ping6 -c broken after svn r269180 Message-ID: <20140917153325.GA69597@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: tjmao@tjmao.net, delphij@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 15:33:39 -0000 Hi Guys, After svn r269180 and MFC to 10-stable r269800 and also to 9- and 8-, ping6 -c have an unintended behaviour. Previously if you did "ping6 -c 3 ", it would send the 3 packets, report the outcome and exit. Now, if the machine to be pinged, does not answer, ping6 will just sit and wait until you press ^C. The current behaviour badly break (hang) scripts that expect the old behaviour. Can these commits be reverted and the original bug be revisited, if need be? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151023 Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za On Mon, Aug 11, 2014 at 06:54:07AM +0000, Xin LI wrote: > Author: delphij > Date: Mon Aug 11 06:54:07 2014 > New Revision: 269800 > URL: http://svnweb.freebsd.org/changeset/base/269800 > > Log: > MFC r269180: > > When interval is set to very small value with limited amount of packets, > ping6(8) would quit before the remote side gets a chance to respond. > > Solve this by resetting the itimer when we have reached the maximum packet > number have reached, but let the other handling to continue. > > PR: bin/151023 > Submitted by: tjmao at tjmao.net > > Modified: > stable/10/sbin/ping6/ping6.c > Directory Properties: > stable/10/ (props changed) > > Modified: stable/10/sbin/ping6/ping6.c > ============================================================================== > --- stable/10/sbin/ping6/ping6.c Mon Aug 11 03:04:16 2014 (r269799) > +++ stable/10/sbin/ping6/ping6.c Mon Aug 11 06:54:07 2014 (r269800) > @@ -1090,8 +1090,14 @@ main(int argc, char *argv[]) > /* signal handling */ > if (seenalrm) { > /* last packet sent, timeout reached? */ > - if (npackets && ntransmitted >= npackets) > - break; > + if (npackets && ntransmitted >= npackets) { > + struct timeval zerotime = {0, 0}; > + itimer.it_value = zerotime; > + itimer.it_interval = zerotime; > + (void)setitimer(ITIMER_REAL, &itimer, NULL); > + seenalrm = 0; /* clear flag */ > + continue; > + } > retransmit(); > seenalrm = 0; > continue;