After exiting the communications program you used for dialing, execute the following command, substituting the name of the serial device you used for the ttyS3 shown here:

# pppd /dev/ttyS3 38400 crtscts defaultroute
            

This command flips the serial line ttyS3 to the PPP line discipline and negotiates an IP link with william. The transfer speed used on the serial port will be 38,400 bps. The crtscts option turns on hardware handshake on the port, which is an absolute must at speeds above 9,600 bps.

The first thing pppd does after starting up is negotiate several link characteristics with the remote end using LCP. Usually, the default set of options pppd tries to negotiate will work, so we won't go into this here, except to say that part of this negotiation involves requesting or assigning the IP addresses at each end of the link.

For the time being, we also assume that william doesn't require any authentication from us, so the configuration phase is completed successfully.

pppd will then negotiate the IP parameters with its peer using IPCP, the IP control protocol. Since we didn't specify any particular IP address to pppd earlier, it will try to use the address obtained by having the resolver look up the local hostname. Both will then announce their addresses to each other.

Usually, there's nothing wrong with these defaults. Even if your machine is on an Ethernet, you can use the same IP address for both the Ethernet and the PPP interface. Nevertheless, pppd allows you to use a different address, or even to ask your peer to use some specific address. These options are discussed later.

After going through the IPCP setup phase, pppd will prepare your host's networking layer to use the PPP link. It first configures the PPP network interface as a point-to-point link, using ppp0 for the first PPP link that is active, ppp1 for the second, and so on. Next, it sets up a routing table entry that points to the host at the other end of the link. In the previous example, pppd made the default network route point to william, because we gave it the defaultroute option. The default route simplifies your routing by causing any IP datagram destined for a nonlocal host to be sent to william; this makes sense since it is the only way it can be reached. There are a number of different routing schemes pppd supports, some of which we will cover later in this chapter.

Of course, the dialing can be automated using the chat(1) command. For more information see the manual page.

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:

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:

ppp:!:10913:0:99999:7:::

Of course, the UID and GID you use depends on which user should own the connection, and how you've created it. You also have to set the password for this 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 example, 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, by adding a line similar to the following to /etc/inittab:

T0:23:respawn:/sbin/mgetty ttyS0

Configure pppd for either PAP or CHAP authentication with the 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 (“ppp”) is the user name which 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. You can specify the options in the options file (see below), or on the command line if you prefer.

Here is a small checklist of tasks to perform, as well as the sequence in which they should be performed in order to have PPP dial-in working on your machine. Make sure each step works before moving on to the next:

Before pppd parses its command-line arguments, it scans several files for default options. These files may contain any valid command-line arguments spread out across an arbitrary number of lines. Hash signs introduce comments.

The first options file is /etc/ppp/options, which is always scanned when pppd starts up. Using it to set some global defaults is a good idea, because it allows you to keep your users from doing several things that may compromise security. For instance, to make pppd require some kind of authentication (either PAP or CHAP) from the peer, you add the auth option to this file. This option cannot be overridden by the user, so it becomes impossible to establish a PPP connection with any system that is not in your authentication databases. Note, however, that some options can be overridden; the connect string is a good example.

The other options file, which is read after /etc/ppp/options, is .ppprc in the user's home directory. It allows each user to specify her own set of default options.

A sample /etc/ppp/options file might look like this:

# Global options for pppd running on romeo
lock                 # use UUCP-style device locking
auth                 # require authentication
usehostname          # use local hostname for CHAP
domain example.com   # our domain name
            

The lock keyword makes pppd comply to the standard UUCP method of device locking. With this convention, each process that accesses a serial device, say /dev/ttyS3, creates a lock file with a name like LCK..ttyS3 in a special lock-file directory to signal that the device is in use. This is necessary to prevent other programs, such as minicom or uucico, from opening the serial device while it is used by PPP.

The next three options relate to authentication and, therefore, to system security. The authentication options are best placed in the global configuration file because they are “privileged” and cannot be overridden by users' ~/.ppprc options files.

IPCP is used to negotiate a number of IP parameters at link configuration time. Usually, each peer sends an IPCP Configuration Request packet, indicating which values it wants to change from the defaults and the new value. Upon receipt, the remote end inspects each option in turn and either acknowledges or rejects it.

pppd gives you a lot of control over which IPCP options it will try to negotiate. You can tune it through various command-line options that we will discuss in this section.

local_addr:remote_addr

PAP, which is offered by many Internet Service Providers, works basically the same way as the normal login procedure. The client authenticates itself by sending a username and a (optionally encrypted) password to the server, which the server compares to its secrets database^[6]. This technique is vulnerable to eavesdroppers, who may try to obtain the password by listening in on the serial line, and to repeated trial and error attacks.

CHAP does not have these deficiencies. With CHAP, the server sends a randomly generated “challenge” string to the client, along with its hostname. The client uses the hostname to look up the appropriate secret, combines it with the challenge and encrypts the string using a one-way hashing function. The result is returned to the server along with the client's hostname. The server now performs the same computation and acknowledges the client if it arrives at the same result.

CHAP also doesn't require the client to authenticate itself only at startup time, but sends challenges at regular intervals to make sure the client hasn't been replaced by an intruder - for instance, by switching phone lines or because of a modem configuration error that causes the PPP daemon not to notice that the original phone call has dropped out and someone else has dialed in.

pppd keeps the secret keys for PAP and CHAP in two separate files called /etc/ppp/pap-secrets and /etc/ppp/chap-secrets. By entering a remote host in one or the other file, you have fine control over whether PAP or CHAP is used to authenticate yourself with your peer, and vice versa.

By default, pppd doesn't require authentication from the remote host, but it will agree to authenticate itself when requested by the remote host. Since CHAP is so much stronger than PAP, pppd tries to use the former whenever possible. If the peer does not support it, or if pppd can't find a CHAP secret for the remote system in its chap-secrets file, it reverts to PAP. If it doesn't have a PAP secret for its peer either, it refuses to authenticate altogether. As a consequence, the connection is shut down.

You can modify this behaviour in several ways. When given the auth keyword, pppd requires the peer to authenticate itself. pppd agrees to use either CHAP or PAP as long as it has a secret for the peer in its CHAP or PAP database. There are other options to turn a particular authentication protocol on or off, but I won't describe them here.

If all systems you talk to with PPP agree to authenticate themselves with you, you should put the auth option in the global /etc/ppp/options file and define passwords for each system in the chap-secrets file. If a system doesn't support CHAP, add an entry for it to the pap-secrets file. That way, you can make sure no unauthenticated system connects to your host.

The next two sections discuss the two PPP secrets files, pap-secrets and chap-secrets. They are located in /etc/ppp and contain triplets of clients, servers and passwords, optionally followed by a list of IP addresses. The interpretation of the client and server fields is different for CHAP and PAP, and it also depends on whether we authenticate ourselves with the peer, or whether we require the server to authenticate itself with us.

When it has to authenticate itself with a server using CHAP, pppd searches the chap-secrets file for an entry with the client field equal to the local hostname and the server field equal to the remote hostname sent in the CHAP challenge. When requiring the peer to authenticate itself, the roles are simply reversed: pppd then looks for an entry with the client field equal to the remote hostname (sent in the client's CHAP response), and the server field equal to the local hostname.

The following is a sample chap-secrets file for romeo^[7]:

# CHAP secrets for romeo.example.com
#
# client                server                  secret           addrs
#---------------------------------------------------------------------
romeo.example.com       william.shakespeare.com "Where art thou" romeo.example.com
william.shakespeare.com romeo.example.com       "To be"          william.shakespeare.com
*                       romeo.example.com       "Capulet"        pub.example.com

When romeo establishes a PPP connection with william, william asks romeo to authenticate itself by sending a CHAP challenge. pppd on romeo then scans chap-secrets for an entry with the client field equal to romeo.example.com and the server field equal to william.shakespeare.com, and finds the first line shown in the example^[8]. It then produces the CHAP response from the challenge string and the secret (Use The Source Luke), and sends it off to william.

pppd also composes a CHAP challenge for william containing a unique challenge string and its fully qualified hostname (romeo.example.com). A CHAP response in the way we discussed, is formatted by william and returned to romeo. pppd then extracts the client hostname (william.shakespeare.com) from the response and searches the chap-secrets file for a line matching william as a client and romeo as the server. The second line does this, so pppd combines the CHAP challenge and the secret To be, encrypts them, and compares the result to william's CHAP response.

The optional fourth field lists the IP addresses that are acceptable for the client named in the first field. The addresses can be given in dotted quad notation or as hostnames that are looked up with the resolver. For instance, if william asks to use an IP address during IPCP negotiation that is not in this list, the request is rejected, and IPCP is shut down. In the sample file shown above, william is therefore limited to using its own IP address. If the address field is empty, any addresses are allowed; a value of - prevents the use of IP with that client altogether.

The third line of the sample chap-secrets file allows any host to establish a PPP link with romeo because a client or server field of * is a wildcard matching any hostname. The only requirements are that the connecting host must know the secret and that it must use the IP address associated with pub.example.com. Entries with wildcard hostnames may appear anywhere in the secrets file, since pppd will always use the best match it can find for the server/client pair.

pppd may need some help forming hostnames. As explained before, the remote hostname is always provided by the peer in the CHAP challenge or response packet. The local hostname is obtained by calling the gethostname function by default. If you have set the system name to your unqualified hostname, you also have to provide pppd with the domain name using the domain option:

# pppd ? domain vbrew.com

This provision appends our domain name to romeo for all authentication-related activities. Other options that modify pppd's idea of the local hostname are usehostname and name. When you give the local IP address on the command line using local:remote and local is a name instead of a dotted quad, pppd uses this as the local hostname.

The PAP secrets file is very similar to CHAP one. The first two fields always contain a username and a hostname; the third holds the PAP secret. When the remote host sends its authentication information, pppd uses the entry that has a server field equal to the local hostname and a user field equal to the username sent in the request. When it is necessary for us to send our credentials to the peer, pppd uses the secret that has a user field equal to the local username and the server field equal to the remote hostname.

A sample PAP secrets file might look like this:

# /etc/ppp/pap-secrets
#
# user          server          secret          addrs
romeo-pap       william         cresspahl       romeo.example.com
william         romeo           DonaldGNUth     william.shakespeare.com

The first line is used to authenticate ourselves when talking to william. The second line describes how a user named william has to authenticate itself with us.

The name romeo-pap in the first column is the username we send to william. By default, pppd picks the local hostname as the username, but you can also specify a different name by giving the user option followed by that name.

When picking an entry from the pap-secrets file to identify us to a remote host, pppd must know the remote host's name. As it has no way of finding that out, you must specify it on the command line using the remotename keyword followed by the peer's hostname. To use the above entry for authentication with william, for example, we must add the following option to pppd's command line:

# pppd ... remotename william user romeo-pap

In the fourth field of the PAP secrets file (and all following fields), you can specify what IP addresses are allowed for that particular host, just as in the CHAP secrets file. The peer will be allowed to request only addresses from that list. In the sample file, the entry that william will use when it dials in (the line where william is the client) allows it to use its real IP address and no other.