Date: Sun, 13 Dec 1998 18:10:53 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: arch@FreeBSD.ORG Subject: Re: IFF_UP, IFF_RUNNING semantics... Message-ID: <19981213181053.47030@uriah.heep.sax.de> In-Reply-To: <8570.913502263@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Dec 12, 1998 at 11:37:43PM %2B0100 References: <E40CBF0361C7D111914000C0F0303D108842@OCTOPUS> <8570.913502263@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
As Poul-Henning Kamp wrote: > Proposed solution: (I don't fully oversee the consequences, albeit it sounds good so far.) > This even solves the extreeme case for PPP where an interface may be > up for one protocol but not for another... Since you mention PPP, i've just verified what sppp does. Basically, it also suffers from some lack of interface flagbits. IFF_UP is used there to express the operator's will to have the interface `up'. For a static link, IFF_RUNNING basically follows IFF_UP. For a dial-on-demand (or passive) link, IFF_RUNNING is down as long as the LCP layer is down. sppp uses this as an indication whether interaction with the underlying transport is required (i. e., the transport is asked to `dial out' the connection). As soon as LCP goes down (since it was negotiated down, or since the underlying transport stopped working (`carrier loss')), IFF_RUNNING is taken back. (From Paul's explanation, I figure this might be somewhat in violation of Stevens.) I noticed like you that IFF_UP cannot be used for this, and needs to stay up all the time; otherwise sppp wouldn't see a single packet from the upper network layers, so it never started to dial out. In addition to the above, IFF_UP is taken back once the LCP magic number logic has detected a loopback (which is supposedly the same as an `ifconfig down' on the interface). There's also some magic to get it back up again once there's some notification about the loopback being fixed. Both these have been mostly inherited from vak's original code. I could not test them in my case, since an ISDN line cannot meaningfully `loop back'. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981213181053.47030>