"Linux Gazette...making Linux just a little more fun!"

When I first began using Linux a couple of years ago, one of my goals was to be able to go on-line. At that time I was constantly rebooting into OS/2 so I could use the internet and this OS schizophrenia was becoming tiresome.

Eventually, after many chatscript iterations and minicom sessions I had a dependable PPP setup. I thought my PPP troubles were over; as time passed my command of the various pppd and chat options began to fade.

This past month my local internet service provider sold its machines and signed up with a large provider in Atlanta. When the accounts were switched over suddenly I could no longer log in and life became a bit too interesting...

A couple of years ago an ISP was happy just to have a set of working log-in scripts which could be distributed to its Windows and Mac customers. At that time most computer users were either hobbyists or professionals, and could be counted on to know what to do with the script. As the internet surged in popularity more and more customers appeared without much knowledge of basic computer usage, and the help-desks and support personnel began to be swamped with requests for set-up help. Naturally, the tendency was to move towards simpler log-in set-ups, if possible without any script at all. As customer interest in text-mode shell accounts waned, a log-in could be accomplished with little more than the username and password. This (I was informed in an e-mail from my provider) was our new log-in sequence: just the username and password.

This sounded simple enough; all I had to do was delete the expect-send sequence selection:  PPP from the chat-script and all would be well. Or so I thought: using this script led to a scrolling list of errors on the console I set up to display all daemon and error messages. It looked like the router I was attempting to connect to was first trying PAP authentication, failing, then trying CHAP authentification, failing that as well; the sequence would repeat until the router would hang up in disgust.

Other variations of the chat-script I tried would result in a "serial line not 8-bit clean" message. I talked with the technician who had set up the local router and he claimed that neither PAP nor CHAP were in use; Win95 log-ins were working fine, so I was on my own.

The next step was to try logging in with Minicom, just to see what the actual log-in screen looked like. I connected and found the expected Username: and Password: prompts. I logged in and a command prompt appeared, with no sign of the typical PPP garbage characters. What now? I typed help and a list of available commands scrolled by. I was logged in to the Cisco router, evidently, and before long I found that I could telnet anywhere I liked. I could run a systat command and see which other users were logged in. The command show hosts provided a list of hosts which I could connect to, and soon I was logged in at the main WWW server in Atlanta! I'd never been logged in at an UltraSparc server running Unix SysVR4 before, and it was great fun exploring the directory structure and running real VI for the first time. I could run pine (and I ended up with yet another e-mail address) and read news with the nn newsreader.

This was all quite diverting, but didn't address the PPP problem. So soon I was back at the router's prompt. I tried typing ppp and the indicative garbage characters appeared. This looked encouraging, so I added this exchange to my chatscript and tried again. The pppd daemon was satisfied this time, and I had what looked like a real PPP session. Unfortunately, it turned out to be limited to the router and I could do nothing with the connection. Another dead-end!

At first I couldn't even log in with OS/2 when I revived an old installation and tried to dial in. Deleting the entire log-in sequence in the dialer got me online again, but even with debugging turned on I still couldn't determine just when the username and password strings were being sent to the server.

On-line once again, I was off to the newsgroups hoping to find advice.

Eventually I came across a posting in comp.os.linux.networking which contained a couple of intriguing statements. The first intimated that Win95 by default makes use of PAP authentification, but the user isn't necessarily informed of the fact. Possibly the Netscape dialer which my ISP distributes was using PAP as well, I thought. The second statement recommended using the pppd option +ua /etc/ppp/pap-secrets. I had seen this option while reading the pppd /etc/ppp/options file, but the manual listed this option as being obsolete, so I'd never tried it.

The posting's author recommended an unusual format for the pap-secrets file, unlike the format recommended in the documentation I'd been reading and unlike the sample included in my PPP installation: just a simple two-line file, the first line containing the username and the second displaying the password. No server or client names, just the two words.

I was surprised and elated when this configuration worked the first time. I had the chat-script simply dial the number and wait for the CONNECT string. The server asked for PAP authentification and I was online without even dealing with the username and password prompts, which I suppose are only for the maintainers of the router.

I'm writing this piece because I suspect that many other servers will probably be adopting similar streamlined login procedures, and the approach I've outlined here may prove useful in at least some of these cases. One thing to remember is that directing the pppd debugging messages to an unused virtual console is very helpful, most easily accomplished by inserting the line:

*.*     /dev/tty8

in your /etc/syslog.conf file.