A.P. Lawrence-Red Hat Linux PPP Server

© January 1999 Tony Lawrence

Ancient stuff; this was written in 1999.

This was a blind job; before I arrived on site I had no idea what the hardware would be. For that matter, either did the customer: when I got there, he was scavenging parts from here and there to put together the machine! The task was to install Linux, and configure it for incoming PPP. I had read some of the PPP HOWTO and it looked like it shouldn't be too bad, so I agreed, while explaining that I am not particularly experienced with Linux (I have done several installs , but very little real use up to now), but that I felt I could get it done in half a day or less. I arrived a little after 9:00 and plunged right into the install.

A normal Linux install

If you've installed Red Hat before, you know it's pretty straightforward. I made one big file system, noted that they still can't do a swap partition over 127 megabyes, and chose to install Everything.

The Red Hat 5.2 install didn't seem significantly different than the 5.1's I've done before. I got lucky with the network card and the video card: what the client pulled out of the scrap heap happened to both be compatible. I did, however, have a problem with the video card; the Xconfigurator assigned it a 640 x 400 resolution. I didn't notice that until I ran startx and it immediately crashed complaining that it had no idea how to do 640 x 400. It took me a few seconds to realize that this wasn't saying 640 x 480, so I edited /usr/lib/X86Config and changed all of those references to 640 x 480. I also noticed that all other resolutions were quoted and this wasn't. I don't know if that's a problem, but I quoted them anyway, and then ran startx. The gray X screen seemed to quiver for a second (probably just EMI from other equipment) and then the Window manager popped to life. I had only specified that the card had 256k of memory, which I assume is why it didn't offer any higher resolutions, but I figured that could be fixed later if anyone cared.

Incoming Modem

I couldn't find a HOWTO or any docs on setting up a modem for incoming calls. Obviously that's the first thing that has to be done for incoming PPP, and in fact the PPP HOWTO says that it won't cover that configuration, and refers to the serial HOWTO, but that only covers programming serial ports, so I was on my own.

I did find a reference to "modemtool", but it has no man page. I ran it, and it brought up a list of serial ports, and asked me to select the one with a modem on it. I did, and it just exited. I don't know what it was supposed to do, but I figured I'd just move on. The experienced Linux folk can stop chuckling now.

The next place I looked was /usr/lib/uucp, and that came up dry. I then tried /etc/uucp and found strange file names. They obviously serve the same purpose as the files I'm used to, but the names are very different, and there was really nothing in them that could give me a quick education. So, for the heck of it, I just typed "cu -l/dev/ttyS0 dir". I had already chowned that device to uucp, and I was surprised when it obliged me by trying to talk to the modem.

Surprised because on every other Unix I would have had to make a Direct entry for /dev/ttyS0 in Devices, and while it's true that there's no Devices file, I sure expected that I'd need to reference it somewhere. But no complaints from cu, although it didn't work.

Bad cable

I quickly determined that it didn't work because they had given me a crossover serial printer cable rather than a modem cable. This effectively made DCE out of the computer, so it couldn't talk to the modem. Another cable was scrounged out of a large box, and this time cu connected.

But it didn't seem too happy. I could enter commands, but it was very hard to tilde back out. For the moment I just assumed a crappy cu, and went on with configuring the modem, setting it for 38400 fixed baud rate and ats0=1 after an at&f. I also thought that perhaps some other process might be competing with me, and was pleased to find "fuser", which told me that there was no other process. Back to the broken cu theory for the moment.

Then I vi'd /etc/inittab. I'd already looked around for available gettys, and it seemed like mgetty was the way to go, so I added an entry for that, specifying a F38400 entry from gettydefs.

No luck

There was no joy at all with this. We tried dialing in from another system using Hyperterminal, and the modem would answer, but no login prompt, and then crap out a few seconds later. I thought perhaps mgetty was broken, so I tried getty. The first cut at that didn't work because the man page was wrong about its location: it's in /usr/sbin, not in /etc as the manual states. However, getty acted just like mgetty, so I went back to mgetty because it has a debugging flag, so I added a -x 9 to inittab and then went to look at the log file. Unfortunately, the man page misdirected me on that also (it's not in /tmp!), but I did find it eventually in /var/logs.

That showed me that mgetty was having trouble with the modem and couldn't see DSR. As this was a brand new USRobotics, and the machine couldn't have been more than a month old, I asked for another cable.

A different cable

This third cable was DB25 to DB25, so I had to switch to COM2. After doing that, nothing worked. The mgetty couldn't talk to the modem at all, and cu couldn't either. This cable, however, had been stolen from a working system, so I had to assume something else was wrong, and it was: dmesg showed two com ports, but not ports 0 and 1: it was 0 and 3! I don't have a clue why this is; I suppose it will make sense someday. I do remember thinking that nothing in SCO was ever this confused, at least not with serial ports!

So, using ttyS3 rather than ttyS1 made mgetty much happier, but I still couldn't log in. It had taken almost 3 hours to get to this point, because in addition to bad cables and the video problems, during all this testing, there were been long periods were I had to stop because I was using one of their incoming voice lines to test with, and I had to give it up as customers called in. During these periods I had continued with the PPP configuration as given in the HOWTO's, creating both a /etc/ppp/options file, a user ppp whose shell would be pppd, and a ~ppp/.ppprc file containing the same options I had in the /etc/ppp/options file. I suppose one of these wasn't necessary, but I had nothing else to do while waiting for the phone line to be free.

I did all that configuration by hand; if there are configuration tools available I didn't find them.

Light dawns!

But still the login prompt wouldn't appear. Things were better; the connection didn't drop, but no login. At this point I wondered if mgetty needed /etc/mgettydefs rather than /etc/gettydefs, so I copied it, but as far as I could tell with "ls -lut", mgetty didn't read either one! And yet, stty showed me that it was running at 38400 baud. Puzzled, I went back to the logs again and this time I noticed that there was a PPP-AUTO or AUTO-PPP (sorry, I forget which) happening. It looked to me like mgetty was doing PPP prior to login, even though I hadn't told it to.

In retrospect, I do remember messing around with the files in /etc/ppp, and I must have turned this feature on without realizing it. At this moment I don't even know exactly what I did, but after switching to DialUp Networking, I immediately got a login prompt, logged in as "ppp" and got my link up with the address I specified. I then realized I had neglected to hook up the network card to the hub, and that I had to scramble to make my next appointment, so I don't know if the proxyarp setting worked, though I expect that it did on the strength of two HOWTO's that referenced that.

I wonder now if modemtool failed because of the bad cables? Maybe it was supposed to do more? When I get a chance (after I get the video working on my home machine!) I'll take another look at that. I also need to look at the /etc/ppp files to better understand how I accidentally triggered mgetty to run PPP automatically. All in all, this was not a terribly frustrating experience. Yes, there was some misleading information, but most of my problems were hardware and site issues. If it were not for that, I might have had this whole thing done in an hour or so, which really isn't bad for an unfamiliar OS.

All modemtool does is make a link from /dev/modem to one of the com ports.

Bruce Garlock (bruceg@tiac.net) wrote:

Here is a link to more information on mgetty.

https://www.leo.org/~doering/mgetty/

In case you don't have it, here is a good site for Linux How-To's:

https://www.linux-howto.com/

For future reference, there are two, somewhat, useful GUI tools for
configuration in RedHat.  In X-Windows, as root, launch 'control-panel'
to get a nice configuration tool, or 'linuxconf'  linuxconf lets you
easily configure dial up ppp users.  I did find the version of linuxconf
that ships with RedHat 5.1 buggy when I was configuring two NIC's.  I
ended up doing it by hand!  They have upgraded linuxconf rather heavily
since that release, though. 
 

I knew about both linuxconf and control-panel, but I missed seeing anything about configuring dial-in for modems or PPP. I guess I'll have to look more closely.

---

Also see: https://www.swcp.com/~jgentry/pers.html and https://papc-rc1.st-and.ac.uk/LDP/LDP/LG/issue36/ali.html Thanks to Bruce Garlock for these links!

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us