Contents:
PPP on Linux
Running pppd
Using Options Files
Using chat to Automate Dialing
IP Configuration Options
Link Control Options
General Security Considerations
Authentication with PPP
Debugging Your PPP Setup
More Advanced PPP Configurations
Like SLIP, PPP is a protocol used to send datagrams across a serial connection; however, it addresses a couple of the deficiencies of SLIP. First, it can carry a large number of protocols and is thus not limited to the IP protocol. It provides error detection on the link itself, while SLIP accepts and forwards corrupted datagrams as long as the corruption does not occur in the header. Equally important, it lets the communicating sides negotiate options, such as the IP address and the maximum datagram size at startup time, and provides client authorization. This built-in negotiation allows reliable automation of the connection establishment, while the authentication removes the need for the clumsy user login accounts that SLIP requires. For each of these capabilities, PPP has a separate protocol. In this chapter, we briefly cover these basic building blocks of PPP. This discussion of PPP is far from complete; if you want to know more about PPP, we urge you to read its RFC specification and the dozen or so companion RFCs.[] There is also a comprehensive O'Reilly book on the topic of Using & Managing PPP, by Andrew Sun.
At the very bottom of PPP is the High-Level Data Link Control (HDLC) protocol, which defines the boundaries around the individual PPP frames and provides a 16-bit checksum.[] As opposed to the more primitive SLIP encapsulation, a PPP frame is capable of holding packets from protocols other than IP, such as Novell's IPX or Appletalk. PPP achieves this by adding a protocol field to the basic HDLC frame that identifies the type of packet carried by the frame.
The Link Control Protocol, (LCP) is used on top of HDLC to negotiate options pertaining to the data link. For instance, the Maximum Receive Unit (MRU), states the maximum datagram size that one side of the link agrees to receive.
An important step at the configuration stage of a PPP link is client authorization. Although it is not mandatory, it is really a must for dialup lines in order to keep out intruders. Usually the called host (the server) asks the client to authorize itself by proving it knows some secret key. If the caller fails to produce the correct secret, the connection is terminated. With PPP, authorization works both ways; the caller may also ask the server to authenticate itself. These authentication procedures are totally independent of each other. There are two protocols for different types of authorization, which we will discuss further in this chapter: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP).
Each network protocol that is routed across the data link (like IP and AppleTalk) is configured dynamically using a corresponding Network Control Protocol (NCP). To send IP datagrams across the link, both sides running PPP must first negotiate which IP address each of them uses. The control protocol used for this negotiation is the Internet Protocol Control Protocol (IPCP).
Besides sending standard IP datagrams across the link, PPP also supports Van Jacobson header compression of IP datagrams. This technique shrinks the headers of TCP packets to as little as three bytes. It is also used in CSLIP, and is more colloquially referred to as VJ header compression. The use of compression may be negotiated at startup time through IPCP, as well.
On Linux, PPP functionality is split into two parts: a kernel component that handles the low-level protocols (HDLC, IPCP, IPXCP, etc.) and the user space pppd daemon that handles the various higher-level protocols, such as PAP and CHAP. The current release of the PPP software for Linux contains the PPP daemon pppd and a program named chat that automates the dialing of the remote system.
The PPP kernel driver was written by Michael Callahan and reworked by Paul Mackerras. pppd was derived from a free PPP implementation[] for Sun and 386BSD machines that was written by Drew Perkins and others, and is maintained by Paul Mackerras. It was ported to Linux by Al Longyear. chat was written by Karl Fox.[]
Like SLIP, PPP is implemented by a special line discipline. To use a serial line as a PPP link, you first establish the connection over your modem as usual, and subsequently convert the line to PPP mode. In this mode, all incoming data is passed to the PPP driver, which checks the incoming HDLC frames for validity (each HDLC frame carries a 16-bit checksum), and unwraps and dispatches them. Currently, PPP is able to transport both the IP protocol, optionally using Van Jacobson header compression, and the IPX protocol.
pppd aids the kernel driver, performing the initialization and authentication phase that is necessary before actual network traffic can be sent across the link. pppd's behavior may be fine-tuned using a number of options. As PPP is rather complex, it is impossible to explain all of them in a single chapter. This book therefore cannot cover all aspects of pppd, but only gives you an introduction. For more information, consult Using & Managing PPP or the pppd manual pages, and READMEs in the pppd source distribution, which should help you sort out most questions this chapter fails to discuss. The PPP-HOWTO might also be of use.
Probably the greatest help you will find in configuring PPP will come from other users of the same Linux distribution. PPP configuration questions are very common, so try your local usergroup mailing list or the IRC Linux channel. If your problems persist even after reading the documentation, you could try the comp.protocols.ppp newsgroup. This is the place where you can find most of the people involved in pppd development.
When you want to connect to the Internet through a PPP link, you have to set up basic networking capabilities, such as the loopback device and the resolver. Both have been covered in Chapter 5, Configuring TCP/IP Networking, and Chapter 6, Name Service and Resolver Configuration. You can simply configure the name server of your Internet Service Provider in the /etc/resolv.conf file, but this will mean that every DNS request is sent across your serial link. This situation is not optimal; the closer (network-wise) you are to your name server, the faster the name lookups will be. An alternative solution is to configure a caching-only name server at a host on your network. This means that the first time you make a DNS query for a particular host, your request will be sent across your serial link, but every subsequent request will be answered directly by your local name server, and will be much faster. This configuration is described in Chapter 6, in "Caching-only named Configuration".
As an introductory example of how to establish a PPP connection with pppd, assume you are at vlager again. First, dial in to the PPP server c3po and log in to the ppp account. c3po will execute its PPP driver. 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 c3po. 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. Expect 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 c3po 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 in the "IP Configuration Options" section.
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 c3po, because we gave it the defaultroute option.[] The default route simplifies your routing by causing any IP datagram destined to a nonlocal host to be sent to c3po; this makes sense since it is the only way they can be reached. There are a number of different routing schemes pppd supports, which we will cover in detail later in this chapter.
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 vlager.vbrew.com lock # use UUCP-style device locking auth # require authentication usehostname # use local hostname for CHAP domain vbrew.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 signal 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.
One of the things that may have struck you as inconvenient in the previous example is that you had to establish the connection manually before you could fire up pppd. Unlike dip, pppd does not have its own scripting language for dialing the remote system and logging in, but relies on an external program or shell script to do this. The command to be executed can be given to pppd with the connect command-line option. pppd will redirect the command's standard input and output to the serial line.
The pppd software package is supplied with a very simple program called chat, which is capable of being used in this way to automate simple login sequences. We'll talk about this command in some detail.
If your login sequence is complex, you will need something more powerful than chat. One useful alternative you might consider is expect, written by Don Libes. It has a very powerful language based on Tcl, and was designed exactly for this sort of application. Those of you whose login sequence requires, for example, challenge/response authentication involving calculator-like key generators will find expect powerful enough to handle the task. Since there are so many possible variations on this theme, we won't describe how to develop an appropriate expect script in this book. Suffice it to say, you'd call your expect script by specifying its name using the pppd connect option. It's also important to note that when the script is running, the standard input and output will be attached to the modem, not to the terminal that invoked pppd. If you require user interaction, you should manage it by opening a spare virtual terminal, or arrange some other means.
The chat command lets you specify a UUCP-style chat script. Basically, a chat script consists of an alternating sequence of strings that we expect to receive from the remote system, and the answers we are to send. We will call them expect and send strings, respectively. This is a typical excerpt from a chat script:
ogin: b1ff ssword: s3|<r1t
This script tells chat to wait for the remote system to send the login prompt and return the login name b1ff. We wait only for ogin: so that it doesn't matter if the login prompt starts with an uppercase or lowercase l, or if it arrives garbled. The following string is another expect string that makes chat wait for the password prompt and send our response password.
This is basically what chat scripts are all about. A complete script to dial up a PPP server would, of course, also have to include the appropriate modem commands. Assume that your modem understands the Hayes command set, and the server's telephone number is 318714. The complete chat invocation to establish a connection with c3po would then be:
$
chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN
By definition, the first string must be an expect string, but as the modem won't say anything before we have kicked it, we make chat skip the first expect by specifying an empty string. We then send ATZ, the reset command for Hayes-compatible modems, and wait for its response (OK). The next string sends the dial command along with the phone number to chat, and expects the CONNECT message in response. This is followed by an empty string again because we don't want to send anything now, but rather wait for the login prompt. The remainder of the chat script works exactly as described previously. This description probably looks a bit confusing, but we'll see in a moment that there is a way to make chat scripts a lot easier to understand.
The -v option makes chat log all activities to the syslog daemon local2 facility.[]
Specifying the chat script on the command line bears a certain risk because users can view a process's command line with the ps command. You can avoid this risk by putting the chat script in a file like dial-c3po. You make chat read the script from the file instead of the command line by giving it the -f option, followed by the filename. This action has the added benefit of making our chat expect sequences easier to understand. To convert our example, our dial-c3po file would look like:
'' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN
When we use a chat script file in this way, the string we expect to receive is on the left and the response we will send is on the right. They are much easier to read and understand when presented this way. The complete pppd incantation would now look like this:
#
pppd connect "chat -f dial-c3po" /dev/ttyS3 38400 -detach \ crtscts modem defaultroute
Besides the connect option that specifies the dialup script, we have added two more options to the command line: -detach, which tells pppd not to detach from the console and become a background process, and the modem keyword, which makes it perform modem-specific actions on the serial device, like disconnecting the line before and after the call. If you don't use this keyword, pppd will not monitor the port's DCD line and will therefore not detect whether the remote end hangs up unexpectedly.
The examples we have shown are rather simple; chat allows for much more complex scripts. For instance, it can specify strings on which to abort the chat with an error. Typical abort strings are messages like BUSY or NO CARRIER that your modem usually generates when the called number is busy or doesn't answer. To make chat recognize these messages immediately rather than timing out, you can specify them at the beginning of the script using the ABORT keyword:
$
chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...
Similarly, you can change the timeout value for parts of the chat scripts by inserting TIMEOUT options.
Sometimes you also need to have conditional execution for parts of the chat script: when you don't receive the remote end's login prompt, you might want to send a BREAK or a carriage return. You can achieve this by appending a subscript to an expect string. The subscript consists of a sequence of send and expect strings, just like the overall script itself, which are separated by hyphens. The subscript is executed whenever the expected string it is appended to is not received in time. In the example above, we would modify the chat script as follows:
ogin:-BREAK-ogin: ppp ssword: GaGariN
When chat doesn't see the remote system send the login prompt, the subscript is executed by first sending a BREAK, and then waiting for the login prompt again. If the prompt now appears, the script continues as usual; otherwise, it will terminate with an error.
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.
All IP interfaces require IP addresses assigned to them; a PPP device always has an IP address. The PPP suite of protocols provides a mechanism that allows the automatic assignment of IP addresses to PPP interfaces. It is possible for the PPP program at one end of a point-to-point link to assign an IP address for the remote end to use, or each may use its own.
Some PPP servers that handle a lot of client sites assign addresses dynamically; addresses are assigned to systems only when calling in and are reclaimed after they have logged off again. This allows the number of IP addresses required to be limited to the number of dialup lines. While limitation is convenient for managers of the PPP dialup server, it is often less convenient for users who are dialing in. We discussed the way that hostnames are mapped to IP addresses by use of a database in Chapter 6. In order for people to connect to your host, they must know your IP address or the hostname associated with it. If you are a user of a PPP service that assigns you an IP address dynamically, this knowledge is difficult without providing some means of allowing the DNS database to be updated after you are assigned an IP address. Such systems do exist, but we won't cover them in detail here; instead, we will look at the more preferable approach, which involves you being able to use the same IP address each time you establish your network connection.[]
In the previous example, we had pppd dial up c3po and establish an IP link. No provisions were taken to choose a particular IP address on either end of the link. Instead, we let pppd take its default action. It attempts to resolve the local hostname, vlager in our example, to an IP address, which it uses for the local end, while letting the remote machine, c3po, provide its own. PPP supports several alternatives to this arrangement.
To ask for particular addresses, you generally provide pppd with the following option:
local_addr:remote_addr
local_addr and remote_addr may be specified either in dotted quad notation or as hostnames.[] This option makes pppd attempt to use the first address supplied as its own IP address, and the second as the peer's. If the peer rejects either of the addresses during IPCP negotiation, no IP link will be established.[]
If you are dialing in to a server and expect it to assign you an IP address, you should ensure that pppd does not attempt to negotiate one for itself. To do this, use the noipdefault option and leave the local_addr blank. The noipdefault option will stop pppd from trying to use the IP address associated with the hostname as the local address.
If you want to set only the local address but accept any address the peer uses, simply leave out the remote_addr part. To make vlager use the IP address 130.83.4.27 instead of its own, give it 130.83.4.27: on the command line. Similarly, to set the remote address only, leave the local_addr field blank. By default, pppd will then use the address associated with your hostname.
After setting up the network interface, pppd will usually set up a host route to its peer only. If the remote host is on a LAN, you certainly want to be able to connect to hosts "behind" your peer as well; in that case, a network route must be set up.
We have already seen that pppd can be asked to set the default route using the defaultroute option. This option is very useful if the PPP server you dialed up acts as your Internet gateway.
The reverse case, in which your system acts as a gateway for a single host, is also relatively easy to accomplish. For example, take some employee at the Virtual Brewery whose home machine is called oneshot. Let's also assume that we've configured vlager as a dialin PPP server. If we've configured vlager to dynamically assign an IP address that belongs to the Brewery's subnet, then we can use the proxyarp option with pppd, which will install a proxy ARP entry for oneshot. This automatically makes oneshot accessible from all hosts at the Brewery and the Winery.
However, things aren't always that simple. Linking two local area networks usually requires adding a specific network route because these networks may have their own default routes. Besides, having both peers use the PPP link as the default route would generate a loop, through which packets to unknown destinations would ping-pong between the peers until their time to live expired.
Suppose the Virtual Brewery opens a branch in another city. The subsidiary runs an Ethernet of its own using the IP network number 172.16.3.0, which is subnet 3 of the Brewery's class B network. The subsidiary wants to connect to the Brewery's network via PPP to update customer databases. Again, vlager acts as the gateway for the brewery network and will support the PPP link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1. This network is illustrated in Figure 24.2 in Appendix A, Example Network: The Virtual Brewery.
When vbourbon connects to vlager, it makes the default route point to vlager as usual. On vlager, however, we will have only the point-to-point route to vbourbon and will have to specially configure a network route for subnet 3 that uses vbourbon as its gateway. We could do this manually using the route command by hand after the PPP link is established, but this is not a very practical solution. Fortunately, we can configure the route automatically by using a feature of pppd that we haven't discussed yet -- the ip-up command. This command is a shell script or program located in /etc/ppp that is executed by pppd after the PPP interface has been configured. When present, it is invoked with the following parameters:
ip-up iface device speed local_addr remote_addr
The following table summarizes the meaning of each of the arguments (in the first column, we show the number used by the shell script to refer to each argument):
In our case, the ip-up script may contain the following code fragment:[]
#!/bin/sh case $5 in 172.16.3.1) # this is vbourbon route add -net 172.16.3.0 gw 172.16.3.1;; ... esac exit 0
Similarly, /etc/ppp/ip-down can be used to undo any actions of ip-up after the PPP link has been taken down again. So in our /etc/ppp/ip-down script we would have a route command that removed the route we created in the /etc/ppp/ip-up script.
However, the routing scheme is not yet complete. We have set up routing table entries on both PPP hosts, but so far none of the hosts on either network knows anything about the PPP link. This is not a big problem if all hosts at the subsidiary have their default route pointing at vbourbon, and all Brewery hosts route to vlager by default. If this is not the case, your only option is usually to use a routing daemon like gated. After creating the network route on vlager, the routing daemon broadcasts the new route to all hosts on the attached subnets.
We already encountered the Link Control Protocol (LCP), which is used to negotiate link characteristics and test the link.
The two most important options negotiated by LCP are the Asynchronous Control Character Map and the Maximum Receive Unit. There are a number of other LCP configuration options, but they are far too specialized to discuss here.
The Asynchronous Control Character Map, colloquially called the async map, is used on asynchronous links, such as telephone lines, to identify control characters that must be escaped (replaced by a specific two-character sequence) to avoid them being interpreted by equipment used to establish the link. For instance, you may want to avoid the XON and XOFF characters used for software handshake because a misconfigured modem might choke upon receipt of an XOFF. Other candidates include Ctrl-l (the telnet escape character). PPP allows you to escape any of the characters with ASCII codes 0 through 31 by specifying them in the async map.
The async map is a 32-bit-wide bitmap expressed in hexadecimal. The least significant bit corresponds to the ASCII NULL character, and the most significant bit corresponds to ASCII 31 decimal. These 32 ASCII characters are the control characters. If a bit is set in the bitmap, it signals that the corresponding character must be escaped before it is transmitted across the link.
To tell your peer that it doesn't have to escape all control characters, but only a few of them, you can specify an async map to pppd using the asyncmap option. For example, if only ^S and ^Q (ASCII 17 and 19, commonly used for XON and XOFF) must be escaped, use the following option:
asyncmap 0x000A0000
The conversion is simple as long as you can convert binary to hex. Lay out 32 bits in front of you. The right-most bit corresponds to ASCII 00 (NULL), and the left-most bit corresponds to ASCII 32 decimal. Set the bits corresponding to the characters you want escaped to one, and all others to zero. To convert that into the hexadecimal number pppd expects, simply take each set of 4 bits and convert them into hex. You should end up with eight hexadecimal figures. String them all together and preprend "0x" to signify it is a hexadecimal number, and you are done.
Initially, the async map is set to 0xffffffff -- that is, all control characters will be escaped. This is a safe default, but is usually much more than you need. Each character that appears in the async map results in two characters being transmitted across the link, so escaping comes at the cost of increased link utilization and a corresponding performance reduction.
In most circumstances, an async map of 0x0 works fine. No escaping is performed.
The Maximum Receive Unit (MRU), signals to the peer the maximum size of HDLC frames we want to receive. Although this may remind you of the Maximum Transfer Unit (MTU) value, these two have little in common. The MTU is a parameter of the kernel networking device and describes the maximum frame size the interface is able to transmit. The MRU is more of an advice to the remote end not to generate frames larger than the MRU; the interface must nevertheless be able to receive frames of up to 1,500 bytes.
Choosing an MRU is therefore not so much a question of what the link is capable of transferring, but of what gives you the best throughput. If you intend to run interactive applications over the link, setting the MRU to values as low as 296 is a good idea, so that an occasional larger packet (say, from an FTP session) doesn't make your cursor "jump." To tell pppd to request an MRU of 296, you give it the option mru 296. Small MRUs, however, make sense only if you have VJ header compression (it is enabled by default), because otherwise you'd waste a large amount of your bandwidth just carrying the IP header for each datagram.
pppd also understands a couple of LCP options that configure the overall behavior of the negotiation process, such as the maximum number of configuration requests that may be exchanged before the link is terminated. Unless you know exactly what you are doing, you should leave these options alone.
Finally, there are two options that apply to LCP echo messages. PPP defines two messages, Echo Request and Echo Response. pppd uses this feature to check if a link is still operating. You can enable this by using the lcp-echo-interval option together with a time in seconds. If no frames are received from the remote host within this interval, pppd generates an Echo Request and expects the peer to return an Echo Response. If the peer does not produce a response, the link is terminated after a certain number of requests are sent. This number can be set using the lcp-echo-failure option. By default, this feature is disabled altogether.
A misconfigured PPP daemon can be a devastating security breach. It can be as bad as letting anyone plug their machine into your Ethernet (and that can be very bad). In this section, we discuss a few measures that should make your PPP configuration safe.
NOTE: Root privilege is required to configure the network device and routing table. You will usually solve this by running pppd setuid root. However, pppd allows users to set various security-relevant options.
To protect against any attacks a user may launch by manipulating pppd options, you should set a couple of default values in the global /etc/ppp/options file, like those shown in the sample file in "Using Options Files", earlier in this chapter. Some of them, such as the authentication options, cannot be overridden by the user, and thus provide reasonable protection against manipulations. An important option to protect is the connect option. If you intend to allow non-root users to invoke pppd to connect to the Internet, you should always add the connect and noauth options to the global options file /etc/ppp/options. If you fail to do this, users will be able to execute arbitrary commands with root privileges by specifying the command as their connect command on the pppd line or in their personal options file.
Another good idea is to restrict which users may execute pppd by creating a group in /etc/group and adding only those users who you wish to have the ability to execute the PPP daemon. You should then change group ownership of the pppd daemon to that group and remove the world execute privileges. To do this, assuming you've called your group dialout, you could use something like:
#
chown root /usr/sbin/pppd
#
chgrp dialout /usr/sbin/pppd
#
chmod 4750 /usr/sbin/pppd
Of course, you have to protect yourself from the systems you speak PPP with, too. To fend off hosts posing as someone else, you should always require some sort of authentication from your peer. Additionally, you should not allow foreign hosts to use any IP address they choose, but restrict them to at most a few. The following section will deal with these topics in detail.
With PPP, each system may require its peer to authenticate itself using one of two authentication protocols: the Password Authentication Protocol (PAP), and the Challenge Handshake Authentication Protocol (CHAP). When a connection is established, each end can request the other to authenticate itself, regardless of whether it is the caller or the callee. In the description that follows, we will loosely talk of "client" and "server" when we want to distinguish between the system sending authentication requests and the system responding to them. A PPP daemon can ask its peer for authentication by sending yet another LCP configuration request identifying the desired authentication protocol.
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.[] 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 behavior 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 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 vlager:[]
# CHAP secrets for vlager.vbrew.com # # client server secret addrs #--------------------------------------------------------------------- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "arttoo! arttoo!" c3po.lucas.com * vlager.vbrew.com "TuXdrinksVicBitter" pub.vbrew.com
When vlager establishes a PPP connection with c3po, c3po asks vlager to authenticate itself by sending a CHAP challenge. pppd on vlager then scans chap-secrets for an entry with the client field equal to vlager.vbrew.com and the server field equal to c3po.lucas.com, and finds the first line shown in the example.[] It then produces the CHAP response from the challenge string and the secret (Use The Source Luke), and sends it off to c3po.
pppd also composes a CHAP challenge for c3po containing a unique challenge string and its fully qualified hostname, vlager.vbrew.com. c3po constructs a CHAP response in the way we discussed, and returns it to vlager. pppd then extracts the client hostname (c3po.vbrew.com) from the response and searches the chap-secrets file for a line matching c3po as a client and vlager as the server. The second line does this, so pppd combines the CHAP challenge and the secret arttoo! arttoo!, encrypts them, and compares the result to c3po'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 c3po 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, c3po 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 vlager 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.vbrew.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(2) 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 the Brewery's domain name to vlager 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 as a name instead of a dotted quad, pppd uses this as the local hostname.
The PAP secrets file is very similar to CHAP's. The first two fields always contain a username and a server name; 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 vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com
The first line is used to authenticate ourselves when talking to c3po. The second line describes how a user named c3po has to authenticate itself with us.
The name vlager-pap in the first column is the username we send to c3po. 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 c3po, for example, we must add the following option to pppd's command line:
#
pppd ... remotename c3po user vlager-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 c3po will use when it dials in -- the line where c3po is the client -- allows it to use its real IP address and no other.
Note that PAP is a rather weak authentication method, you should use CHAP instead whenever possible. We will therefore not cover PAP in greater detail here; if you are interested in using it, you will find more PAP features in the pppd(8) manual page.
By default, pppd logs any warnings and error messages to syslog's daemon facility. You have to add an entry to syslog.conf that redirects these messages to a file or even the console; otherwise, syslog simply discards them. The following entry sends all messages to /var/log/ppp-log:
daemon.* /var/log/ppp-log
If your PPP setup doesn't work right away, you should look in this log file. If the log messages don't help, you can also turn on extra debugging output using the debug option. This output makes pppd log the contents of all control packets sent or received to syslog. All messages then go to the daemon facility.
Finally, the most drastic way to check a problem is to enable kernel-level debugging by invoking pppd with the kdebug option. It is followed by a numeric argument that is the sum of the following values: 1 for general debug messages, 2 for printing the contents of all incoming HDLC frames, and 4 to make the driver print all outgoing HDLC frames. To capture kernel debugging messages, you must either run a syslogd daemon that reads the /proc/kmsg file, or the klogd daemon. Either of them directs kernel debugging to the syslog kernel facility.
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:[]
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 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 "Configuring the mgetty Daemon" 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:
persist holdoff 600
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.