Date: Wed, 18 Aug 2004 13:50:46 +0100 From: Brian Somers <brian@Awfulhak.org> To: John Polstra <jdp@polstra.com> Cc: Roman Kurakin <rik@cronyx.ru> Subject: Re: cvs commit: src/sys/net if_tap.c Message-ID: <20040818135046.4f298f97@dev.lan.Awfulhak.org> In-Reply-To: <XFMail.20040813101044.jdp@polstra.com> References: <411CF2CC.4000809@cronyx.ru> <XFMail.20040813101044.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Aug 2004 10:10:44 -0700 (PDT), John Polstra <jdp@polstra.com> 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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040818135046.4f298f97>