19.3 Objective 4: Configure and Use PPP

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, which is not covered on LPI Exam 102). 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.

In order 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 15 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 dialup 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 dialup connection are 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 referred to as /dev/ttyS0 and /dev/ttyS1.^[8] 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:

^[8] These device names were /dev/cua0 and /dev/cua1 in previous Linux kernels. They're referred to as COM1: and COM2: in MS-DOS and Windows.

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:

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^[10] 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 dialup configuration:

^[10] The chat program is unrelated to the notion of Internet Relay Chat (IRC) and chat rooms.

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 PPP 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 OKfrom 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 (a dedicated Cisco dialup server managed by an ISP) 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

~ÿ}#.!}!C} }4}"}&} }*} } }%}&bGab}'}"}(}"V}?~~ÿ}#.!}!
4}"}&} }*} } }%}&bGab}'}"}(}".ÿ~~

The garbled text at the end is a terminal's attempt to render the binary PPP data as characters and is expected.

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

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 dialup 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.

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 (115200 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. It is common to set map to 00000000 to allow all 8 bits to be used.

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 syslog 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 dialup 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 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.^[11]

^[11] It is likely that your distribution's automated for PPP scripts are capable of reestablishing terminated PPP links, perhaps 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,^[12] the results of which can be found in /var/log/messages:^[13]

^[12] Your chat script location may vary; this example is from a Red Hat Linux system.

^[13] 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 dialup 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 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 the Exam 102.

On the Exam Be aware that PAP, CHAP, and MSCHAP exist and may be required for some dialup 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 both 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. While creating this file is trivial (it just contains your username and password on two separate lines), this file and PAP are beyond the scope of the LPIC Level 1 exams.

19.3.1.8 Too many variables

Unfortunately, many of the elements involved in a dialup 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 dialup 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 in order to make dialup 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. Nonchat authentication schemes and the setup of PPP servers are also beyond the scope of this exam.