B.4 PPP

Most PPP implementations fall into one of two categories: They are implemented either in the kernel just below the IP layer in the TCP/IP stack or in user space and use a tunnel driver, such as the FreeBSD tun driver, to communicate with the TCP/IP stack. Our test systems include examples of both methods. The Linux and Solaris operating systems use an in-kernel PPP implementation. If we think of PPP as another layer in the TCP/IP stack, then the top of the PPP layer talks to the IP layer, and the bottom of the PPP layer talks, by default, to the serial port device driver.

Actually, Linux uses a hybrid method, in which the encapsulation is done in the kernel, but the LCP/NCP processing is done by the user-space pppd program. PPP packets containing IP datagrams are handled in the kernel and do not go through pppd.

It is often convenient to have the bottom of the PPP layer communicate with the STDIN and STDOUT interfaces of a user-space process. This is usually accomplished by having PPP connect to a pseudo-tty device [Stevens 1992] rather than an actual serial device. Because we are interested primarily in using PPP to form tunnels, this is the mode that we usually use, and we see examples of this use in the text.

The help screen from pppd, shown in Figure B.3, lists the most important options and gives us an idea of how to use it.

Figure B.3. Common pppd Options

[View full width] pppd -h pppd version 2.4.1 Usage: pppd [ options ], where options are: <device> Communicate over the named device <speed> Set the baud rate to <speed> <loc>:<rem> Set the local and/or remote interface IP addresses. Either one may be omitted. asyncmap <n> Set the desired async map to hex <n> auth Require authentication from peer connect <p> Invoke shell command <p> to set up the serial line crtscts Use hardware RTS/CTS flow control defaultroute Add default route through interface file <f> Take options from file <f> modem Use modem control lines mru <n> Set MRU value to <n> for negotiation See pppd(8) for more options.

In addition to the options listed in the help screen, we use the notty option, which tells pppd to open a pseudo-tty so that we can intercept the PPP frames and encapsulate them in our tunnels. These are only a few of the options; the typeset man page for pppd is more than 20 pages.

Several additional scripts can help control the PPP link. After authentication succeeds, pppd will check for the existence of the /etc/ppp/auth-up script. If it exists, pppd will execute it. If the auth-up script is executed, /etc/ppp/auth-down will be executed, if it exists, when the link is torn down. Similar scripts are run when an NCP starts and stops. For example, /etc/ppp/ip-up is run when the link is ready to send or receive IP datagrams, and /etc/ppp/ip-down is run when the link is no longer able to send or receive IP datagrams.

An excellent discussion of the internals of pppd and how the kernel and user-space portions of the PPP implementation communicate is given in PPP Design and Debugging [Carlson 2000]. As mentioned in Chapter 2, Carlson's book is an excellent reference for the specifics of PPP and explains the functioning of its state machines in detail.

FreeBSD's PPP implementation is an example of the second method, in which all the PPP processing takes place in a user-space program. In FreeBSD, this program is called ppp. Figure B.4 shows how ppp communicates with the TCP/IP stack. Note the similarity to our gtunnel implementation. The figure shows ppp communicating with a serial driver for its external I/O, but we most often set it to communicate either through the TCP/IP stackwhen we encapsulate PPP frames in TCP segments or UDP datagramsor through its STDIN and STDOUT, as we do in Chapter 6, where we want it to communicate through another program.

Because ppp is so flexible and has so many optionsthe typeset man page is almost 50 pagesalmost all the configuration is done by a configuration file. The command line interface merely selects a mode, a "system," and a few options, as we see from the help screen:

bsd# ppp -h
usage: ppp [-auto | -foreground | -background | -direct |
-dedicated | -ddial | -interactive] [-nat] [-quiet]
[-unit N] [system ...]

The first set of choices is the mode, which selects the manner in which ppp will operate.

The modes are:

auto	ppp opens the connection to the TCP/IP stack and becomes a daemon but takes no further action until it sees an IP packet, at which point it will attempt to contact the remote system.
foreground	ppp attempts to establish a connection with the remote system immediately but does not become a daemon.
background	ppp attempts to establish a connection with the remote system immediately. If ppp succeeds, it becomes a daemon; otherwise, it exits with a failure status.
direct	This mode causes ppp to listen for connections rather than trying to establish a connection to the remote system.
dedicated	This mode indicates that ppp has a dedicated connection to the remote system, and no chat script is necessary to establish communications.
ddial	This mode is like the auto mode, but will try to reestablish the connection if it is dropped.
interactive	This mode allows a user to control its operation interactively.

The -nat option enables ppp's internal NAT. The -quiet option inhibits ppp's output to the console when it starts. The -unit N option allows the user to specify which tun interface ppp should use. Without this option, ppp will use the first available tun device.

The configuration of PPP connections is specified in the /etc/ppp/ppp.conf file. The ppp.conf file can contain configurations for several PPP connections. These configurations are separated into named sections in the file, and it is one or more of these that the user specifies for "system . . ." when calling ppp.

Chapter 6 has an example of a ppp.conf file when ppp is used in an SSL tunnel. Figure B.5 is another example, showing the configuration for a normal ppp session over a serial line.

Figure B.5. A Typical ppp.conf File

[View full size image]

Most of the options in the configuration file are self-explanatory. Because the options are discussed in detail in the ppp man page and because there are so many of them, we won't discuss them further.

In addition to reading the ppp.conf file, ppp checks for the existence of a /etc/ppp/ppp.linkup file when a link is established. If the file exists, its contents are executed. It can set ppp parameters or run arbitrary scripts. A common use is to set a route, as we do in Chapter 6. Similarly, the /etc/ppp/ppp.linkdown script is checked when the link is torn down.