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 From owner-freebsd-arch Sun Dec 13 12:50:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08133 for freebsd-arch-outgoing; Sun, 13 Dec 1998 12:50:01 -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 MAA08101 for ; Sun, 13 Dec 1998 12:49:56 -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 VAA17114 for ; Sun, 13 Dec 1998 21:49:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA32014 for freebsd-arch@freebsd.org; Sun, 13 Dec 1998 21:49:52 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06074 for ; Sun, 13 Dec 1998 12:24:02 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id VAA01006; Sun, 13 Dec 1998 21:23:43 +0100 (CET) To: Joerg Wunsch cc: arch@FreeBSD.ORG Subject: Re: IFF_UP, IFF_RUNNING semantics... In-reply-to: Your message of "Sun, 13 Dec 1998 18:10:53 +0100." <19981213181053.47030@uriah.heep.sax.de> Date: Sun, 13 Dec 1998 21:23:42 +0100 Message-ID: <1004.913580622@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a version of SPPP here which works a lot better than the one in the tree, but it breaks, I'm almost certain, the if_ar, if_cx and if_sr drivers we have. And the ISDN stuff as well. On the other hand, as I said: it works. What I would really like to do is to untangle this enough that the underlying structure shines sufficiently through to let other people use this intelligently. What needs done is more or less: Move the "struct if" back into the drivers private space, so that other encapsulations can use the same interface struct. Clean up the boundary between sppp and the driver. Add a "ifconfig encapsulation {ppp|cisco-hdlc|...}" facility Yank the cisco stuff from isppp and put it in its own encapsulation method. As I said, this will break everything we have in there, so I think the right way to do it is for me to clone if_sppp* and do it "right" then migrate the other drivers to use it, that way I don't yank the rug on anybody else. The ISDN stuff will benefit from this as well, but I will need for somebody else to take that bit, I don't have an ISDN card running right now, and will not have time for that also. The interface I have in mind is something like this: An encapsulation (PPP, Cisco-HDLC) provides a struct like this for each instance: struct if_hdlc_encap { char *name; void (*up)(struct if_hdlc_encap *); void (*down)(struct if_hdlc_encap *); void (*input)(struct if_hdlc_encap *, struct mbuf *); int (*ioctl)(struct ifnet *ifp, u_long cmd, void *data) int (*destroy)(struct if_hdlc_encap *); struct if_hdlc_driver *driver; void *privatep; int *privatei; }; An HDLC driver provides one of these for each channel: struct if_hdlc_driver { void (*open)(struct if_hdlc_driver *, char *dialinfo); void (*close)(struct if_hdlc_driver *); void (*output)(struct if_hdlc_driver *); int (*ioctl)(struct ifnet *ifp, u_long cmd, void *data) struct if_hdlc_encap *encapsulation; struct ifnet pp_if; void *privatep; int *privatei; }; A generic system ioctl routing is used to change encapsulation (down & destroy old one, create new one, hook it up to interface). How does that sound ? I think I can have this done PDQ so you can have some actual code to look at. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message