Michael Talbot-Wilson wrote: > > Are you sure that mgetty AutoPPP doesn't support CHAP? As I understand it > > It requires the pppd login option, which according to the pppd man > page requires PAP. There is absolutely no reason why any ppp option (except for the one that sets which device to use) should not work normally when pppd has been started from mgetty's AutoPPP configuration. I believe you have probably misread the mgetty documentation if you got the impression that you had to use the login option to pppd. This is only in order to get an entry in your system's utmp or wtmp files. Since a PPP session is basically a network connection rather than a login, and is/can be perfectly adequately logged elsewhere (you could even use mgetty to start a script that records an entry in the utmp/wtmp files, and then starts pppd), I really don't see the point in trying to get ppp sessions logged as if someone had logged in. > See also the mgetty 1.1.12 Makefile: > > # If you want to auto-detect incoming PPP calls (with PAP authorization), > # add -DAUTO_PPP. Not needed if PPP callers want to get a real "login:" The AutoPPP code will not be compiled in to mgetty if you don't include that #define. It's not needed if you don't want to use AutoPPP. I don't see what this has to do with the pppd authentication you choose to use. > Likewise the example login.cfg line turns PAP on and CHAP off. I'd advise against specifying any options to pppd on the command line; use a file in /etc/ppp/peers to store all the options you need. That way, you can more easily store multiple configurations (for testing, or for multiple possible situations), and you can put comments in too, to remind yourself why you're doing something in a particular way. > > (I've only used PAP), mgetty just looks for the PPP handshaking after it > > picks up the line, then fires up pppd with whatever options the AutoPPP > > (or options file) specifies. At this point mgetty shouldn't be involved. Quite. > > I agree that testing the shell login before proceeding to PPP setup is > > important. I've made the same recommendation to others on this list > > several times in the past few weeks. Thanks for emphasizing that. Like I said before, if your remote end is capable of PAP or CHAP, why use a shell login? > By the same token, whatever the merits of AutoPPP, he can disregard > it while he is getting something to work, and look into it > afterwards from a more mature standpoint. The main problem I had when getting ppp dialins set up was ensuring that all the /dev/modem and /dev/cua0 lines were replaced absolutely everywhere by /dev/ttyS0. Other than that, AutoPPP is *really* simple. Windows diallers will by default be set up to work with it, and a chat script only needs to get as far as the modem "CONNECT" string before handing over to ppp. You can look in the mgetty log to check that AutoPPP has been triggered. If it has, then any problems are in the ppp configuration. If not, then the other end has probably not started its own ppp for some reason. Sure you can test *most* of your ppp config by dialling in, loggin in to your normal account, starting ppp manually etc., but don't be afraid of AutoPPP. It's simple. Honest. Remember to Have Fun, whichever way you go about it... Nick -- Nick Phillips ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [EMAIL PROTECTED]
