Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!serv.hinet.net!news.uoregon.edu!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!usenet.cisco.com!iverson From: iverson@cisco.com (Tim Iverson) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Problem with PPPD dial script(s) Date: 9 Jul 1996 23:29:15 GMT Organization: cisco Lines: 42 Message-ID: <4ruq0b$or7@cronkite.cisco.com> References: <HUFF.96Jul7001252@sunspot.tiac.net> <4rrf2f$fg@anorak.coverform.lan> NNTP-Posting-Host: rottweiler.cisco.com In article <4rrf2f$fg@anorak.coverform.lan>, Brian Somers <brian@awfulhak.demon.co.uk> wrote: |Robert Huff (huff@sunspot.tiac.net) wrote: |: I'm setting up kernel PPP and the sample scripts provided in |: the Handbook don't work. | |This is one of the reasons I stopped using it. ijppp (prog: ppp) |is infinitely better - it dials, allows auto-connection, firewalling |etc. I'd advise this approach. Hmmm. Iijppp is easier to play with for simple setups, but it has serious drawbacks. The biggest being that it never execs another program to do anything for it -- everything must be done from within iijppp's own internal scripting language. I need to configure NAT from a dynamically assigned IP when I dial up. Can't do this with iijppp. |ijppp allows you to run "chat" from within the program (fork/exec). |Here, chat inherits the serial descriptors, reads & writes the necessary No. At least not in the 2.1-release that I have. Take a look at the source; iijppp never calls the chat program. Instead, some of the source code from chat was copied into iijppp. IMHO, this is poor engineering and a major design flaw -- always use an existing tool unless there is some large gain to be made by not doing so. BTW, the documentation does say that iijppp fork/execs chat. It lies. ;-) |If you *really* have a good reason for not using ijppp, the only |satisfactory way I found was to get your modem not to drop carrier |on loss of DTR for a long time (say 255 hundreths of a second). |You can then write a script that kermits, then *immediately* |runs pppd. As long as pppd re-opens the line within your 2.55 |second limit, you keep carrier. Umm, no. Open the line, run chat, run pppd, close line. If you need special dialing, use xchat from tUUCP (it can do anything). Documentation seems to indicate that pppd can open the line and then run chat for you, but none of the example scripts use this capability. - Tim Iverson iverson@lionheart.com