Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!constellation!news.uoknor.edu!ns1.nodak.edu!netnews.nwnet.net!reuter.cse.ogi.edu!cs.uoregon.edu!usenet.ee.pdx.edu!fastrac.llnl.gov!lll-winken.llnl.gov!ames!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!amd!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: PPP under BSD (have a heart) Message-ID: <Ctv3tI.7yE@calcite.rhyolite.com> Organization: Rhyolite Software Date: Mon, 1 Aug 1994 15:17:42 GMT References: <31aajm$gfe@euterpe.owl.de> <31guqq$ghs@Starbase.NeoSoft.COM> <bakulCttyCM.7n@netcom.com> Lines: 81 In article <bakulCttyCM.7n@netcom.com> bakul@netcom.com (Bakul Shah) writes: > >What is needed is to transparently keep the if interface up while >the serial line goes up and down. Probably a bunch of additional >ioctls. When a line is idle for a (configurable) period of time, >the if_ppp driver signals pppd. I prefer having the daemon do the counting based on traffic indications from the kernel. > Pppd drops the line and does any >other cleanup processing (such as removing any lock files, >updating accounting records etc.). When there is some traffic, >if_ppp again signals pppd. Now ppd will try to acquire *some* >serial line, go through the login dialog and (assuming the other >end is smart enough) tell the driver to use the new serial line. >The driver also signals pppd if the line is dropped by the other >side. If the other side dials in first on some serial line, it >should be possible to continue with the same if interface. It is possible. That is what is called "symmetric demand dialing." At least, that's what I call it. > This >will allow either side to drop the connection when idle and >restablish it when warranted. Some additional machinery is >needed to verify that the ``other side'' is the same peer and to >finally break the connection. No additional machinery is needed. Simply use whatever you used to autheticate the peer when the connection was set up initially, probably PAP, CHAP, and/or getty/login. > This scheme will also allow use of >the same serial lines by other programs during periods of >inactivity. Yep. Other programs including other SLIP and PPP links, and cu and UUCP. > Going from this to use of multiple serial lines >between the same two end points (to increase bandwidth) is a >much smaller step. No, in practice, multi-link is a bigger a mess as demand dialing. There are a bunch of niggling technical details that mess things up. For example, how do you figure out when to add or drop links? For another example, consider the political pain the IETF PPP working group has suffered getting as far as it has with PPP multi-link. What I call "Brute Force and Ignorant multi-link" works fine for IP traffic, and is supported by at least one ISDN hub maker and a workstation vendor. > You'd also want to control the `either side >can dialup the other side' feature via an ioctl. No, I think it's best to put all of that stuff in the daemon. If you do demand dialing, you probably want to start out with the network interface up and apparently alive but without a serial line. Grab first serial line when there is traffic. Another thing you've missed is the mechanism to decide which traffic counts as activity. For example, you do not want to grab a serial line every time some time daemon decides to check clocks. DNS traffic and ICMP errors are also best not counted as activity. Some people (including me) think it is nice to have ICMP Echo-Requests count as activity. Some people might prefer to not count other traffic as activity, such as incoming FTP connections, so you need at least one bit in the kernel for each UDP port, TCP port, and ICMP type (or an equivalent data structure if you don't have room for ~128Kbits of table). You also might want to vary your timeouts based on the state of higher layer protocols. I find it convenient to use a 5 minute timeout when there are active TCP connections, but 30 seconds otherwise. I keep track of active TCP connections by noticing SYN's and FIN's in the Van Jacobson header compression code and state tables. I'm ridiculously proud of that kludge. Vernon Schryver vjs@rhyolite.com