While configuring PPP to dial in to a network like the Internet is the
most common application, there are those of you who have more
advanced requirements. In this section we'll talk about a few of the more
advanced configurations possible with PPP under Linux.
Running pppd as a server is just a matter of
configuring a serial tty device to invoke pppd with
appropriate options when an incoming data call has been received. One
way to do this is to create a special account, say ppp, and give it a script or program as a
login shell that invokes pppd with these
options. Alternatively, if you intend to support PAP or CHAP
authentication, you can use the mgetty program to
support your modem and exploit its “/AutoPPP/” feature.
To build a server using the login method, you add a line similar
to the following to your /etc/passwd
file:[1]
ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin |
If your system supports shadow passwords, you also need to add an entry
to the
/etc/shadow file:
Of course, the UID and GID you use depends on which user you wish to
own the connection, and how you've created it. You also have to set the
password for the mentioned account using the passwd command.
The ppplogin script might look like this:
#!/bin/sh
# ppplogin - script to fire up pppd on login
mesg n
stty -echo
exec pppd -detach silent modem crtscts |
The mesg command disables other users from writing
to the tty by using, for instance, the write
command. The stty command turns off character
echoing. This command is necessary; otherwise, everything the peer sends would
be echoed back to it. The most important pppd
option given is –detach
because it prevents pppd from detaching from the
controlling tty. If we didn't specify this option, it would go to the
background, making the shell script exit. This in turn would cause the
serial line to hang up and the connection to be dropped. The
silent option causes pppd to
wait until it receives a packet from the calling system before it
starts sending. This option prevents transmit timeouts from occurring when
the calling system is slow in firing up its PPP client. The
modem option makes
pppd drive the modem control lines of the serial
port. You should always turn this option on when using
pppd with a modem. The crtscts
option turns on hardware handshake.
Besides these options, you might want to force some sort of
authentication, for example, by specifying auth on
pppd 's command line or in the global
options file. The manual page also discusses more specific options
for turning individual authentication protocols on and off.
If you wish to use mgetty, all you need to do is
configure mgetty to support the serial device your modem
is connected to (see Section 4.6.1” for details),
configure pppd for either PAP or CHAP authentication
with appropriate options in its options file, and finally,
add a section similar to the following to your
/etc/mgetty/login.config file:
# Configure mgetty to automatically detect incoming PPP calls and invoke
# the pppd daemon to handle the connection.
#
/AutoPPP/ - ppp /usr/sbin/pppd auth -chap +pap login |
The first field is a special piece of magic used to detect that
an incoming call is a PPP one. You must not change the case of this string;
it is case sensitive. The third column is the username that appears in
who listings when someone has logged in. The rest of the
line is the command to invoke. In our example, we've ensured that PAP
authentication is required, disabled CHAP, and specified that the system
passwd file should be used for authenticating users.
This is probably similar to what you'll want. Remember, you can specify
the options in the options file or on the command line
if you prefer.
Here is a small checklist of tasks to perform and the sequence you should
perform them to get PPP dial in working on your machine. Make sure each
step works before moving on to the next:
Configure the modem for auto-answer mode. On Hayes-compatible modems,
this is performed using a command like ATS0=3. If you're
going to be using the mgetty daemon, this isn't necessary.
Configure the serial device with a getty type of command to
answer incoming calls. A commonly used getty variant is
mgetty.
Consider authentication. Will your callers authenticate using PAP,
CHAP, or system login?
Configure pppd as server as described in this section.
Consider routing. Will you need to provide a network route to callers?
Routing can be performed using the ip-up script.
When there is IP
traffic to be carried across the link, demand dialing causes your telephone modem to
dial and to establish a connection to a remote host. Demand dialing is most useful
when you can't leave your telephone line permanently switched to your
Internet provider. For example, you might have to pay timed local calls, so it might be cheaper to have the telephone line
switched on only when you need it and disconnected when you aren't
using the Internet.
Traditional Linux solutions have used the diald
command, which worked well but was fairly tricky to
configure. Versions 2.3.0 and later of the PPP daemon have built-in
support for demand dialing and make it very simple to configure. You
must use a modern kernel for this to work, too. Any of the later 2.0
kernels will work just fine.
To configure pppd for demand dialing, all you need to do
is add options to your options file or the
pppd command line. The following table summarizes the
options related to demand dialing:
A simple demand dialing configuration would therefore look something
like this:
demand
holdoff 60
idle 180 |
This configuration would enable demand dialing, wait 60 seconds before
re-establishing a failed connection, and drop the link if 180 seconds pass
without any active data on the link.
Persistent dialing is what people who have
permanent dialup connections to a network will want to use. There is a
subtle difference between demand dialing and persistent dialing. With
persistent dialing, the connection is automatically established as soon
as the PPP daemon is started, and the persistent aspect comes into play
whenever the telephone call supporting the link fails. Persistent dialing ensures that the link is always
available by automatically rebuilding the connection if it fails.
You might be fortunate to not have to pay for your telephone calls;
perhaps they are local and free, or perhaps they're paid by your
company. The persistent dialing option is extremely useful in this
situation. If you do have to pay for your telephone calls, then you
have to be a little careful. If you pay for your telephone calls on a
time-charged basis, persistent dialing is almost certainly not what
you want, unless you're very sure you'll be using the connection fairly
steadily twenty-four hours a day. If you do pay for calls, but they
are not time charged, you need to be careful to protect yourself
against situations that might cause the modem to endlessly redial. The
pppd daemon provides an option that can help reduce
the effects of this problem.
To enable persistent dialing, you must include the persist option in one of your
pppd options files. Including this option alone is
all you need to have pppd automatically
invoke the command specified by the connect option to rebuild the connection
when the link fails. If you are concerned about the modem redialing
too rapidly (in the case of modem or server fault at the
other end of the connection), you can use the holdoff option to set the minimum amount
of time that pppd will wait before attempting to
reconnect. This option won't solve the problem of a fault costing you money
in wasted phone calls, but it will at least serve to reduce the impact
of one.
A typical configuration might have persistent dialing options that
look like this:
The holdoff time is specified in seconds. In our example,
pppd waits a full five minutes before redialing
after the call drops out.
It is possible to combine persistent dialing with demand dialing,
using idle to drop the link if
it has been idle for a specified period of time. We doubt many users
would want to do so, but this scenario is described briefly in the
pppd manual page, if you'd like to pursue it.
