Section 19.3. Objective 4: Configure Linux as a PPP Client

19.3. Objective 4: Configure Linux as a PPP Client

The Point-to-Point Protocol (PPP) is a method of constructing a network connection between two systems using a serial interface. Usually, this interface is a pair of modems connected by a telephone call over a switched voice network. However, PPP isn't specifically tied to the use of modems and can also work with a direct serial connection using a null modem cable (sometimes known as a crossover cable. When PPP is implemented on a Linux system, it creates a new network interface, usually ppp0, which is configured for use with TCP/IP and an IP address.

To use PPP, your kernel must be compiled with PPP support . Most distributions include PPP support in the kernels they install, but if yours doesn't or if you build your own kernels, you must select PPP Support under Network Device Support in your kernel configuration (see Chapter 13 for information on compiling kernels).

19.3.1. Clients and Servers

PPP is a peer-to-peer protocol, in which there is no technical difference between the two systems sharing a PPP link. When used for dial-up communications, however, it is convenient to think of the system making the call as a PPP client and the system being called as a PPP server. Linux can do both jobs simultaneously if multiple serial interfaces are available, but this section covers only the client-side configuration as required by Exam 102.

19.3.1.1. Serial ports and modems

The only hardware required to create a PPP dial-up connection is a serial interface and a modem. These may be separate devices, including an external modem device cabled to an internal serial interface. Internal modems implement both the port and the modem hardware on a single board, reducing costs. Serial ports are a standard item on most small computers and communicate using RS-232, an old standard for serial communications with terminals, modems, and other devices. On Linux, serial ports are accessed via device files, usually /dev/ttyS0, /dev/ttyS1, and so on. (The standard serial devices are referred to as COM1: and COM2: in MS-DOS and Windows. On older Linux systems, you may see devices named /dev/cuan. These older names were deprecated several years ago.) In addition, a link for a default modem device, /dev/modem, is often made to point to the serial port where a modem is attached. For example:

 crw-------  1 root tty   Apr 25 18:28 /dev/ttyS0 crw-------  1 root tty   May  5  1998 /dev/ttyS1 lrwxrwxrwx  1 root root  Dec  7 23:04 /dev/modem -> ttyS0 

Each byte of information to be sent through a serial interface is sent bit by bit at a periodic rate known as the baud rate. In the early days of modems, data was transmitted over the phone at the same baud rate as it was encoded by the serial port. However, modern modems compress data before transmitting it and can accommodate higher data rates from host systems. As a result, the serial port typically runs at its fastest speed, allowing the modem to independently set a line speed after negotiating with the server's modem. By keeping the data rate between computer and modem high, the modem has a constant stream of data ready for transmission, maximizing throughput.

Built into each serial interface is a data buffer capable of holding a finite amount of information. When serial data enters the buffer faster than it can be removed, a data overrun occurs unless the data flow is stopped through the use of a flow control signal. For example, when a system is sending data into a modem through a serial interface, the modem must send a stop signal when it has no more room in its buffer and later send a start signal when the buffer again has free space. The result is that, while the modem sends a constant stream to the other modem, the serial interface is running bursts of data managed by flow controls. In simple cases such as terminals, two flow control characters named XON and XOFF are transmitted in the serial data stream and are interpreted as controls to hardware. However, PPP uses the entire serial byte and is less efficient if control characters are allowed, so another means known as ready-to-send (RTS) and clear-to-send (CTS) is used for flow control. These signals are included in standard serial cables and allow hardware flow control between devices.

19.3.1.2. PPP overview

PPP connections are established through these general steps:

1. A serial connection is created with a remote PPP server. This involves setting local serial port parameters, setting local modem parameters, and instructing the modem to dial the telephone number of the PPP server. After the modem on the other end answers, the two modems negotiate the best possible link speed, depending on their capabilities and the quality of the telephone line.

2. User account authentication information is supplied to the PPP server. More than one method exists for this task, but in many cases, the PPP server simply provides clear text login and password prompts, and the client responds in the same way.

3. PPP is started on the client. Many servers automatically initiate PPP upon successful authentication, while others offer a sort of command-line interface where PPP can be started with a command.

4. The PPP server selects an IP address from a pool of addresses reserved for PPP connections and provides it to the client in plain text. The server then initiates a binary data stream to link the PPP client and server software.

5. The PPP client software uses the temporarily assigned IP address to configure the new interface and its required routes. (Additional information beyond the IP address can be provided to clients using DHCP. Examples include the default gateway and DNS servers.) It then joins the server in establishing the PPP binary data stream.

19.3.1.3. Chat scripts

Most of this process requires a dialog between the calling computer and its modem and subsequently the PPP server, including the interpretation of responses. For example, it's common to begin the entire process by instructing the modem to reset itself, ensuring that settings from previous communications sessions don't affect the current session. After the reset instruction is completed, the modem responds with OK on a line by itself. It would be impractical to proceed if the reset command fails, so the modem's response must be tested, and further modem commands presented only if the appropriate responses are received. This command/response dialog function is implemented using the chat utility, intended specifically for use with modems. chat executes a script that contains lines of text to send to the modem as well as fragments of what to expect from the modem itself. The chat scripts also allow for default actions to typical modem responses, such as the ability to abort a call attempt if the modem reports a busy signal. Here is a typical chat script for a simple dial-up configuration:

 ABORT BUSY ABORT ERROR ABORT 'NO CARRIER' ABORT 'NO DIALTONE' ABORT 'Invalid Login' ABORT 'Login incorrect' '' ATZ OK ATDT8005551212 CONNECT '' ogin: jdoe ssword: jdoepasswd TIMEOUT 5 > ppp 

In this chat script, the first six lines use the ABORT keyword to provide strings that chat should consider to be fatal errors, terminating the call attempt. Any of the modem or server responses BUSY, ERROR, NO CARRIER, NO DIALTONE, Invalid Login, and Login incorrect will cause the script to terminate.

Each subsequent line of this example is constructed using two items: an expected response, followed by a send string. Here, the first response is simply no response at all, indicated by the empty quotes, "". This causes chat to issue a send string consisting of the modem reset sequence ATZ without expecting any input. chat then waits for the next expected response, which should be an OK from the modem indicating a successful reset. After verifying that, the modem dials as a result of the ATDT command, and chat waits to receive a CONNECT response from the modem. If the modem returns BUSY instead of CONNECT, chat terminates as a result of the ABORT string at the top of the file. When CONNECT is received, chat simply sends a carriage return, indicated in the script by another set of empty quotes, to stimulate the PPP server to prompt for authentication (some PPP servers require this stimulation, others don't). Because this will be the first text from the server, it's possible that the first character could be garbled, so only the fragment ogin: is used to look for the login: prompt. In response, a username (jdoe) is sent, and then the user is prompted for a password. After successful authentication, this particular PPP server requires PPP to be started using the ppp command at the > prompt.

Note that strings with spaces or no characters are delimited with quotes and that a depiction of carriage returns isn't required. Neither must separate lines be used for each expect/send pair. This example could also look like this:

 ABORT BUSY ABORT ERROR ABORT 'NO CARRIER' ABORT 'NO DIALTONE' ABORT 'Invalid Login' ABORT 'Login incorrect' '' ATZ OK ATDT8005551212 CONNECT '' ogin: jdoe ssword: jdoepasswd TIMEOUT 5 > ppp 

It's important that chat is given send/expect commands in pairs. Creating the file with separate lines for each pair makes for easy comprehension, but it isn't really necessary. Regardless of the chat script format, here's what the conversation looks like from chat's point of view:

 ATZ OK ATDT8005551212 CONNECT 31200/ARQ/V34/LAPM/V42BIS User Access Verification login:jdoe Password:<jdoepasswd> mxusw5>ppp Entering PPP mode. Async interface address is unnumbered (Loopback0) Your IP address is 192.168.50.211. MTU is 1500 bytes 

19.3.1.4. The PPP daemon

In addition to the kernel support mentioned at the beginning of this Objective, the PPP daemon (pppd ) is required to run PPP on Linux. When used by a client computer to establish a dial-up connection, pppd does not start at boot time and remain active as do many other daemons. Instead, it runs as directed by users or automatically when a network connection is required. pppd has a large number of available options, but only a general understanding is necessary for Exam 102.

On the Exam

You should be able to create a basic chat script from scratch, providing basic login and PPP server information.

Syntax

 pppd [device] [speed] [options] 

Description

Start the PPP daemon on device with serial interface rate speed. The speed parameter is almost always set to the maximum speed of the serial interface (115,200 bits per second) to allow the modem to keep data compression running at full capacity.

Frequently used options

asyncap map

This option can be used to eliminate bits of the serial byte from use by pppd, preserving control characters. Each bit in map is excluded. If map is set to 0, all 8 bits will be used. Any other setting will cause performance degradation to some degree. The default is to escape all control characters, so this option should be used if possible.

connect script-command

This option calls the script that handles the modem setup and authentication, usually chat. script-command is a complete command string that initiates the modem dialup sequence, including chat, its parameters, and the chat script. Since it includes the chat command, options, and a script, the entire script-command should be quoted so that pppd does not attempt to interpret it as options.

crtscts

This option instructs pppd to set the serial port to use hardware flow control (CTS/RTS).

debug

This option turns on debugging. Information is logged to syslogd and also to the calling terminal, unless pppd detached (see the nodetach option).

defaultroute

By setting this option, pppd creates a default route in the routing table for the new PPP device. This is a typical need for a dial-up system without network access. Note, however, that a networked system that already has a default route to its network interface would then have two default routes, which doesn't make sense. In this case, the administrator must determine how best to configure the routing for PPP connections.

ipparam name

If this option is included, name is included as the sixth argument to /etc/ppp/ip-up, a script that handles a few logging and network details after the PPP link is established.

lock

This instructs pppd to establish a lock file to claim exclusive access to the device.

nodetach

This option prevents pppd from putting itself in the background, instead remaining attached to the calling terminal. This is helpful for interactive use and debugging.

persist

In situations in which you want PPP to be constantly available (such as with dedicated modem links or direct system-to-system cable links), use the persist option. pppd attempts to reestablish a terminated PPP connection. This can protect your PPP link from modem power failure, line degradation, or line interruption. Note that this capability is specifically mentioned in Objective 4 and is likely to appear on Exam 102. (It is likely that your distribution's automated PPP scripts are capable of reestablishing terminated PPP links without the persist option. This can be achieved with the use of a while loop.)

On the Exam

You should have a firm understanding of pppd and the nature and form of its options. In particular, be familiar with the persist option.

19.3.1.5. Manual PPP connection

Here's a simple one-command example of a manual PPP connection, using the chat script presented earlier. In the pppd command, each option appears on a separate line for clarity, though this is not required in practice:

 # /usr/sbin/pppd /dev/ttyS0 115200 \     nodetach \     lock \     debug \     crtscts \     asyncmap 00000000     connect "/usr/sbin/chat -vf \         /etc/sysconfig/network-scripts/chat-ppp0" 

pppd first calls the chat script, the results of which can be found in /var/log/messages (chat logs output as a result of the -v option, as passed to pppd in the quoted chat command.):

 kernel: PPP: version 2.3.3 (demand dialing) kernel: PPP line discipline registered. kernel: registered device ppp0 pppd[1291]: pppd 2.3.7 started by root, uid 0 chat[1295]: abort on (BUSY) chat[1295]: abort on (ERROR) chat[1295]: abort on (NO CARRIER) chat[1295]: abort on (NO DIALTONE) chat[1295]: abort on (Invalid Login) chat[1295]: abort on (Login incorrect) chat[1295]: send (ATZ^M) chat[1295]: expect (OK) chat[1295]: ATZ^M^M chat[1295]: OK chat[1295]:  -- got it chat[1295]: send (ATDT8005551212^M) chat[1295]: expect (CONNECT) chat[1295]: ^M chat[1295]: ATDT8005551212^M^M chat[1295]: CONNECT chat[1295]:  -- got it chat[1295]: send (^M) chat[1295]: expect (ogin:) chat[1295]:  31200/ARQ/V34/LAPM/V42BIS^M chat[1295]: ^M chat[1295]: ^M chat[1295]: User Access Verification^M chat[1295]: ^M chat[1295]: login: chat[1295]:  -- got it chat[1295]: send (jdow^M) chat[1295]: expect (ssword:) chat[1295]: jdoe^M chat[1295]: Password: chat[1295]:  -- got it chat[1295]: send (<jdoepasswd>^M) chat[1295]: timeout set to 5 seconds chat[1295]: expect (>) chat[1295]: ^M chat[1295]: ^M chat[1295]: ^M chat[1295]: mxusw5> chat[1295]:  -- got it chat[1295]: send (ppp^M) pppd[1291]: Serial connection established. pppd[1291]: Using interface ppp0 pppd[1291]: Connect: ppp0 <--> /dev/modem pppd[1291]: local  IP address 192.168.100.202 pppd[1291]: remote IP address 192.168.100.1 

The calling terminal, remaining attached to pppd due to the nodetach option, shows debugging information:

 Serial connection established. Using interface ppp0 Connect: ppp0 <--> /dev/ttyS0 sent [LCP ConfReq id=0x1 <asyncmap 0x0>    <magic 0x5f6ecfaa> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x46 <asyncmap 0xa0000>    <magic 0x77161be5> <pcomp> <accomp>] sent [LCP ConfAck id=0x46 <asyncmap 0xa0000>    <magic 0x77161be5> <pcomp> <accomp>] rcvd [IPCP ConfReq id=0x3e <addr 192.168.100.1>] sent [LCP ConfReq id=0x1 <asyncmap 0x0>    <magic 0x5f6ecfaa> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x47 <asyncmap 0xa0000>    <magic 0x7716279c> <pcomp> <accomp>] sent [LCP ConfAck id=0x47 <asyncmap 0xa0000>    <magic 0x7716279c> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>    <magic 0x5f6ecfaa> <pcomp> <accomp>] sent [IPCP ConfReq id=0x1 <addr 192.168.1.30> rcvd [IPCP ConfReq id=0x3f <addr 192.168.100.1>] sent [IPCP ConfAck id=0x3f <addr 192.168.100.1>] rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] sent [IPCP ConfReq id=0x2 <addr 192.168.1.30>] rcvd [IPCP ConfNak id=0x2 <addr 192.168.100.96>] sent [IPCP ConfReq id=0x3 <addr 192.168.100.96>] rcvd [IPCP ConfAck id=0x3 <addr 192.168.100.96>] local  IP address 192.168.1.220 remote IP address 192.168.1.1 Script /etc/ppp/ip-up started; pid = 3759 Script /etc/ppp/ip-up finished (pid 3759), status = 0x0 

At this point, the PPP connection is up and these two new routes should appear in the routing table:

• A route to the new ppp0 interface

• A default route through the new ppp0 interface

For example (here, the Met and Ref columns, mentioned earlier, are deleted for clarity):

 # route Kernel IP routing table Destination   Gateway       Genmask         Flags Use Iface 192.168.100.1 *             255.255.255.255 UH      0 ppp0 192.168.1.30  *             255.255.255.255 UH      0 eth0 192.168.1.0   *             255.255.255.0   U       0 eth0 127.0.0.0     *             255.0.0.0       U       0 lo default       192.168.100.1 0.0.0.0         UG      0 ppp0 

When your dial-up session is complete, you can terminate pppd easily by entering Ctrl-C on the calling terminal:

 ^C pppd[1291]: Terminating on signal 2. pppd[1291]: Connection terminated. pppd[1291]: Connect time 5.9 minutes. pppd[1291]: Sent 22350 bytes, received 34553266 bytes. pppd[1291]: Exit. 

When pppd is running in the background, terminate a PPP link by sending a SIGINT or SIGTERM signal to the running pppd.

19.3.1.6. Authentication protocols

In the examples presented in this Objective, authentication with the PPP server is handled by means of a clear text username/password dialog and implemented using chat. This is a common setup, but three additional authentication techniques also exist. All of them embed the authentication information into the PPP data stream instead of using a clear text dialog prior to initiating PPP. These methods maintain authentication information, or secrets, in a file.

PAP

The Password Authentication Protocol (PAP) is initiated by the connecting client, which sends a username/password pair. Secret information is stored in /etc/ppp/pap-secrets.

CHAP

The Challenge Handshake Authentication Protocol (CHAP) is initiated by the server, which sends a challenge. The challenge data contains the server's name, and the client must respond with its name plus a new value derived from the challenge information and the stored authentication information. For CHAP, this information is stored in /etc/ppp/chap-secrets. CHAP may also include additional challenges over the life of the PPP connection.

MSCHAP

This is a Microsoft-specific variant of CHAP implemented on Windows NT systems using RAS. It is supported by pppd, although special provisions are required. See the Linux PPP HOWTO for more information if you're dialing into a Windows NT RAS server using MSCHAP.

The authentication information stored in the secrets files for PAP and CHAP has a common format but is beyond the scope of Exam 102.

On the Exam

Be aware that PAP, CHAP, and MSCHAP exist and may be required for some dial-up situations.

19.3.1.7. PPP over ISDN

Objective 4 makes casual mention of initiating ISDN connections using PPP over ISDN technology, but ISDN devices are beyond the scope of both LPIC Level 1 Exams. That said, getting PPP running on an existing ISDN setup using supported hardware is very similar to a modem connection. Most ISDN terminal adapters supported by Linux behave much like modems, so the same connection methods may be employed. A chat script sets up the terminal adapter and instructs it to dial (probably with a special dial string that implies the ISDN BRI phone numbers), and pppd continues as usual. However, ISDN connections will likely require the use of one of the authentication protocols already mentioned. If PAP is used, the corresponding pap-secrets file is necessary.

19.3.1.8. Too many variables

Unfortunately, many of the elements involved in a dial-up PPP connection lack specific standards:

• Modems from various manufacturers may require unique settings to be made prior to dialing the PPP server. This means that setup strings included in chat scripts may be hardware-specific. The Linux Modem HOWTO contains information on modem requirements.

• Authentication and PPP startup schemes vary among ISPs and other PPP servers. Therefore, the configuration of a dial-up interface depends on the server's requirements. Specific information from the PPP server provider is necessary.

• PPP automation techniques vary among Linux distributions. While pppd comes with a default configuration style, there's no guarantee that your distribution will fully utilize it. This is particularly true for systems that include custom configuration tools that may use special configuration files and scripts.

On the Exam

PPP setup can be confusing, particularly when your Linux distribution adds additional complexity to make dial-up carefree. Be sure that you've been able to establish a PPP session with a server through both automated configuration and manual methods. You'll also need to understand how and why chat is used, how expect/send strings are constructed, how to get debugging information from pppd, and the routing implications of PPP (the default route). You don't need to memorize all of pppd's many options or understand each script associated with automated startup of pppd, as these are beyond the scope of Exam 102. Non-chat authentication schemes and the setup of PPP servers are also beyond the scope of this exam.