Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!netcomsv!netcom.com!bakul From: bakul@netcom.com (Bakul Shah) Subject: Re: PPP under BSD (have a heart) Message-ID: <bakulCtw9DA.B61@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <31aajm$gfe@euterpe.owl.de> <31guqq$ghs@Starbase.NeoSoft.COM> <bakulCttyCM.7n@netcom.com> <Ctv3tI.7yE@calcite.rhyolite.com> Date: Tue, 2 Aug 1994 06:15:09 GMT Lines: 70 vjs@calcite.rhyolite.com (Vernon Schryver) writes: >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. I agree. But... won't this get unwieldy when you have a zillion such connections? The daemon has to poll all these Z interfaces! >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. Don't know about PAP & CHAP but getty/login are not enough unless you put some additional constraints. What happens when the same person dials in twice, once to run PPP and once to login and run a shell? What happens when both logins are for PPP? Which one gets connected? What happens if I dial in for PPP from machine A at work, then I go home without breaking the connection and now login from machine B? >> 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? I would add and drop links when told to do so by the local side or remote side (subject to related policies -- just like your daemon based policies for a single link PPP). Until some experience is gained it does not make to sense cast such policies in concrete. The key issue is identifying that the peer on a new link is the same entity as the one currently talking to us. Apart from policies, the only other issue is how the interface code keeps all the links equally busy. >For another example, consider the political pain the IETF PPP working >group has suffered getting as far as it has with PPP multi-link. I meant `a smaller *technical* step'. >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. [etc.] I agree! So.... is this all written up and agreed upon by the IETF PPP WG?! Identifying the peer entity is such a central and/or useful concept in all sorts of situations that it makes sense to me to have a completely separate standard way of doing it and just use that in every case (perhaps with a varying level of trust and inversely varying speed of identification). Bakul Shah <bvs@BitBlocks.com>