From owner-cvs-src@FreeBSD.ORG Wed Aug 18 12:51:05 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973E016A4CF; Wed, 18 Aug 2004 12:51:05 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A36743D1D; Wed, 18 Aug 2004 12:51:04 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i7ICol3i027948; Wed, 18 Aug 2004 13:50:47 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Wed, 18 Aug 2004 13:50:46 +0100 From: Brian Somers To: John Polstra Message-Id: <20040818135046.4f298f97@dev.lan.Awfulhak.org> In-Reply-To: References: <411CF2CC.4000809@cronyx.ru> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Roman Kurakin Subject: Re: cvs commit: src/sys/net if_tap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2004 12:51:05 -0000 On Fri, 13 Aug 2004 10:10:44 -0700 (PDT), John Polstra wrote: > On 13-Aug-2004 Roman Kurakin wrote: > > John Polstra wrote: > >>That's pretty much correct. IFF_UP is an administrative control > >>that expresses the desired state of the interface. The driver never > >>changes IFF_UP. IFF_RUNNING is the driver's idea of the _actual_ > >> > >> > > PPP state machine can remove IFF_UP. For example if connection is not > > persistent and link > > was broken for any reason. > > I call that a bug. > > John Well, I think this is only a little bug :*) Ppp is initially told by the administrator either to keep the interface up (and re-establish broken connections) or to treat a broken connection as fatal. In the first instance it leaves IFF_UP on and uses the same excuse that assigning an address to an interface uses to turn in on in the first place. In the second instance it shuts down the interface and uses the inverse of the above excuse! So I think the little bug is that ppp implementations generally keep the IFF_UP flag in line with whether there's an address on the interface or not. I think it's ``little'' because that's pretty much the most useful thing to do as the ppp process is there to manage the interface - taking over the job of the administrator in effect. Interestingly enough, ppp(8) cheats a little further when it comes to PPPoE where it brings the underlying ethernet interface up if it's not already up. There were two reasons for this; the first was that it's not very useful not having data passed back and forth through the interface, and the second (and real) reason is that connecting a netgraph node to an interface that isn't yet IFF_RUNNING upset some drivers such as fxp in a rather fatal way that I was never quite able to reproduce. -- Brian Don't _EVER_ lose your sense of humour !