The pppd daemon begins setting up the connection parameters with the remote by exchanging IP addresses, then sets communications values. After that is done, pppd sets the network layer to use the PPP link by setting the interface to /dev/ppp0 (if it’s the first PPP link active on the machine). Finally, pppd establishes a kernel routing table entry to point to the machine on the other end of the PPP link.

Checking Problems

The pppd daemon echoes all warnings and error messages to the syslog facility. If you use the -v option with the chat script, chat’s messages are also sent to syslog. If you have trouble with your PPP connections, you can check the syslog for details and try to isolate the problem. A word of warning about the -v option: Everything gets echoed to the logs, including usernames and passwords. This is an option you should avoid using unless necessary for debugging purposes.

Unless there is an entry in the /etc/syslog.conf file that redirects incoming error and warning messages to another file, the messages are discarded by syslog. To save the messages from pppd and chat, add this line to the /etc/syslog.conf file:

daemon.*    /tmp/ppp-log

This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of the syslog.conf file insist on tabs to separate the columns instead of spaces. After your script is working, remember to remove this line or the log file will grow quite large!

PPP Authentication

PPP is a wonderful protocol for modem-based communications, but it has one major problem: It has security holes large enough to drive a bus through. If even slightly incorrectly configured, anyone can use the PPP line to get into your machine or use the PPP line to get out to other systems. To help prevent this, authentication is often used. Authentication essentially makes sure that each end of the connection is who they say they are and is allowed to use the link.

There are two authentication schemes used by PPP: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While simple, PAP has a major flaw: Anyone can tap into the line and monitor the passwords being sent.

CHAP solves this problem, and hence, is the most favored form of authentication for PPP links. CHAP enables one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. And because CHAP doesn’t authenticate only at start time but at random intervals throughout the connection, it is even more powerful.

When two machines connect, they don’t use authentication unless explicitly instructed to do so. (See the auth entry in the /etc/ppp/options file discussed earlier.) When authentication is active, one end tries to use CHAP first; then, if that fails because the other end doesn’t support CHAP, it will use PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the auth entry in the /etc/ppp/options file. If your connections don’t all support authentication, then those connections will fail if auth is specified.

The information needed for both CHAP and PAP are kept in two files called /etc/ppp/chap-secrets and /etc/ppp/pap-secrets, respectively. When authentication is active, one end checks the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the chap-secrets and pap-secrets files. If you configure both chap-secrets and pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can connect to your machine.

The /etc/ppp/chap-secrets file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself or is issuing a challenge to the remote. When the local machine has to authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the client field that matches the local hostname and the server field equal to the remote hostname, then uses the string to build the authentication message. Such an entry in the /etc/ppp/chap-secrets file looks like this:

#   client            server           string       addresses

merlin.tpci.com   big_guy.big_net.com   “I hate DOS”

This entry uses the string I hate DOS to build an authentication message back to big_guy.big_net.com. The quotations are necessary to surround the string in the file. (We’ll look at the addresses column in a moment.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this:

#   client            server           string      addresses

merlin.tpci.com   big_guy.big_net.com   “I hate DOS”

merlin.tpci.com   chatton.cats.com      “Meow, Meow, Meow”

merlin.tpci.com   roy.sailing.ca        “Hoist the spinnaker”

When your machine is sending the challenge, the process is reversed. The pppd daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this:

#   client            server           string      addresses

big_guy.big_net.com    merlin.tpci.com     “Size isn’t everything”