Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In part 1 we looked at a simple setup for creating and sharing a dial-up Internet connection. Today we’ll learn how to build a dial-in server. A dial-in server is useful for remote system administration, remote user access, or building a low-cost WAN. A Linux dial-in server can serve as a gateway for both Linux and Windows boxes.
Getting Gettys
There are three primary elements to a Linux dial-in server:
- inittab
- mgetty
- pppd
A getty – ‘get tty’ – is a daemon that monitors serial lines. Modems are represented by ttySN — /dev/ttyS0, /dev/ttyS1, dev/ttyS2, and /dev/ttyS3. There are all kinds of different Linux and Unix gettys. mgetty is especially good — it supports data, fax, and voice, and integrates nicely with pppd. If your system does not have mgetty, I recommend getting it.
Configuring mgetty
At root, open /etc/mgetty/login.config for editing. (Note: check your documentation for file locations, as they may vary.) We want to add this line:
/AutoPPP/ – – /usr/sbin/pppd file /etc/ppp/options.server
Note that a similar line may already be present:
/AutoPPP/ – a_ppp /usr/sbin/pppd auth -chap +pap login debug
These represent two different ways of doing the same thing. The first line, which I prefer, puts all the pppd options into a file named /etc/ppp/options.server. You can name this file anything you like. (The docs I learned from use /etc/ppp/options.server, and I’m too lazy to think of something else.) PPP is a peer-to-peer protocol, so our dial-in server options could also go into /etc/ppp/options. Since it’s being used as a server, I like this method as it eases the strain on my aging brain.
Configure inittab
mgetty is not run from the command line; it’s a daemon. Start it at boot with an entry in inittab:
S0:2345:respawn:/sbin/mgetty ttyS0 /dev/ttyS0
Note the tricky bits — on my system the modem is an external serial modem at /dev/ttyS0. I’ve selected runlevels 2,3,4, and 5. Use appropriate values for your system. Then run init -q to start it up.
Configure etc/ppp/options.server
One way to configure etc/ppp/options.server is to copy the contents of /etc/ppp/options, comments and all, and then edit it for dial-in server duties. This is the good and educational method. The fast way is to start fresh and copy the following (be sure to have only one command per line):
asyncmap 0
modem
crtscts
lock
require-pap
refuse-chap
proxyarp
192.168.1.10:192.168.1.11
‘asyncmap’ could be a chapter by itself — set the value to zero to turn off escaping control characters, unless you have a need to manage escaping control characters (now doesn’t that inspire some interesting mental images…) Do not leave this out, because then by default, all control characters will be escaped, and nothing will work right.
The ‘modem’ and ‘crtcts’ lines enable hardware flow control. I can’t imagine using software (xonxoff) flow control, unless you have an unimaginably ancient or bizarre modem. Fortunately, both ancient and bizarre modems are well-supported in Linux, if this is indeed your situation.
‘lock’ is for locking the serial device so that no other system functions can take it over.
The ‘require-pap’ and ‘refuse-chap’ lines are examples of selecting the type of authentication.
‘proxyarp’ is very important. All machines dialing in to your server must have an IP address. If they don’t, proxyarp assigns one to the serial port. The first IP address belongs to the server, and the second one, delimited by a colon, is assigned to the user dialing in. Obviously, you don’t want to have any duplicate IPs on the subnet.
PAP/CHAP
You can use either PAP or CHAP for authentication, but CHAP is more secure. Username/passwords are stored in /etc/ppp/chap-secrets or /etc/ppp/pap-secrets. On the server, you’ll need to enter all the username/password pairs that are allowed access. The clients need only their own username/password. For the simplest PAP authentication, add the ‘noauth’ option to /etc/ppp/options on all the clients that are authorized to connect to your dial-in server (see the PPPD Auth Gotcha from part 1 for more on this).
The format is the same for both, and supplying the username and password is sufficient:
user server secret address
username * password *
Of course, server names and IP addresses can be added for increased security and control.
/etc/passwd Authentication
Alternatively, you can do away with PAP/CHAP entirely by adding the following to /etc/ppp/options:
login
refuse-pap
refuse-chap
This will tell PPP to authenticate against Linux system passwords, rather than hassling with secrets files.
Good to Go
At this point, we have a functioning dial-in server that you can use for connecting to a fileserver, as a gateway to other PCs inside the network, or as a quick and easy WAN link. (See the Linux Network Administrator’s Guide for how to set up routing using ip-up and ip-down).
Dial-on-Demand and Persistent Dialing are two useful methods of keeping a client connected:
Dial-on-Demand
This is the frugal way to manage a dialup connection. To activate dial-on-demand – when sending email, for example – add these lines to /etc/ppp/options:
demand
holdoff 60
idle 360
‘demand’ means simply run on demand. PPP starts partway, and then waits for the ‘connect’ command.
‘holdoff’ sets, in seconds, how to long to wait between redials.
‘idle’ will disconnect ppp after the configured number of seconds of no activity on the line.
Persistent Dialing
To keep the line alive constantly, add these lines to /etc/ppp/options:
persistent
holdoff 60
This tells ppp to stay connected, and to redial after 60 seconds if the connection is broken.
That wraps up our two-part look at building dial-up and dial-in servers for Linux. I hope you’ve enjoyed it!
Resources
Linux Network Administrator’s Guide, 2nd Edition
Modem HOW-TO
Linux Dial-in Server Setup Guide
Linux PPP HOWTO
»
See All Articles by Columnist Carla Schroder
