Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!europa.eng.gtefsd.com!emory!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: PPP under BSD (have a heart) Message-ID: <CttsxM.40A@calcite.rhyolite.com> Organization: Rhyolite Software Date: Sun, 31 Jul 1994 22:24:58 GMT References: <michaelv.775404734@ponderous.cc.iastate.edu> <31aajm$gfe@euterpe.owl.de> <31guqq$ghs@Starbase.NeoSoft.COM> Lines: 25 In article <31guqq$ghs@Starbase.NeoSoft.COM> peter@Starbase.NeoSoft.COM (Peter da Silva) writes: > >Anyone thought of a good way to get pppd to dial on demand? I've had this >idea of hooking pppd up via a pty to a daemon that dialed when it got >activity from pppd and then went into passthrough mode until it saw there >was no activity for a while and dropped the connect. > >This would of course depend on TCP/IP's nice behaviour of happily resending >stuff until things come up. You really do not want to rely on TCP retransmissions in this case. The code I use does symmetric demand dialing and it takes about 26 seconds to get the line up, getty's happy, and so on. From what I've seen 25-35 sec is typical of v.32bis modems. By that time, TCP retransmission timers have backed off to the moon. If you hope for TCP timers, you'll be waiting literally minutes, and have a good chance that TCP will give up entirely without doing any good. However, since my PPP and SLIP code saves the last 50 packets queued while waiting for the in packets to transmit when the link does come up, it all works fine. At worst, the remote side may see a bunch of back-to-back retransmissions. (no, I take the Man's wages for writing it, and so it's not available.) Vernon Schryver vjs@rhyolite.com