From owner-freebsd-arch Sun Dec 13 09:27:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18813 for freebsd-arch-outgoing; Sun, 13 Dec 1998 09:27:10 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18802 for ; Sun, 13 Dec 1998 09:27:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA15098 for ; Sun, 13 Dec 1998 18:26:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA30755 for freebsd-arch@freebsd.org; Sun, 13 Dec 1998 18:26:57 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18270 for ; Sun, 13 Dec 1998 09:21:05 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id SAA25719 for arch@FreeBSD.ORG; Sun, 13 Dec 1998 18:20:56 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id SAA16492; Sun, 13 Dec 1998 18:10:55 +0100 (MET) (envelope-from j) Message-ID: <19981213181053.47030@uriah.heep.sax.de> Date: Sun, 13 Dec 1998 18:10:53 +0100 From: J Wunsch To: arch@FreeBSD.ORG Subject: Re: IFF_UP, IFF_RUNNING semantics... Reply-To: Joerg Wunsch References: <8570.913502263@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <8570.913502263@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Dec 12, 1998 at 11:37:43PM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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