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
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
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:
# ppplogin - script to fire up pppd on login
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
# 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
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:
This option specifies that the PPP link should be placed in demand dial mode. The PPP network device will be created, but the connect command will not be used until a datagram is transmitted by the local host. This option is mandatory for demand dialing to work.
This option allows you to specify which data packets are to be considered active traffic. Any traffic matching the specified rule will restart the demand dial idle timer, ensuring that pppd waits again before closing the link. The filter syntax has been borrowed from the tcpdump command. The default filter matches all datagrams.
This option allows you to specify the minimum amount of time, in seconds, to wait before reconnecting this link if it terminates. If the connection fails while pppd believes it is in active use, it will be re-established after this timer has expired. This timer does not apply to reconnections after an idle timeout.
If this option is configured, pppd will disconnect the link whenever this timer expires. Idle times are specified in seconds. Each new active data packet will reset the timer.
A simple demand dialing configuration would therefore look something
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
A typical configuration might have persistent dialing options that
look like this:
The holdoff time is specified in seconds. In our example,
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.