Configuring PPP

Two protocols support connection to the Internet via modem: SLIP (Serial Line Internet Protocol) and PPP (Point to Point Protocol). As the name suggests, SLIP supports only IP. It is an older, less rugged protocol. Its only advantage is that it may be available where PPP isn't. If you have the choice, always take PPP: it differs from SLIP in being able to handle multiple protocols simultaneously, and it’s also used on many DSL links (PPP over Ethernet or PPPoE). In this chapter, we’ll look only at PPP.

PPP can perform a number of functions:

• It dials and establishes a phone connection if necessary. Strictly speaking, this isn't part of the PPP specification, but it is supported by most PPP implementations.
• It performs authentication to ensure that you are allowed to use the connection.
• It performs negotiation to decide what kind of protocol to use over the link. You might think, " that’s OK, I'm just using IP, " but in fact there are a number of different ways to transmit IP datagrams over a PPP link. In addition, the other end may be able to handle non-Internet protocols such as X.25, SNA and Novell's IPX.
• It can perform line quality monitoring to ensure that the modems are able to understand each other.

FreeBSD provides two versions of PPP:

• Traditional BSD implementations of IP are located in the kernel, which makes for more efficiency. The corresponding implementation of PPP is referred to as kernel PPP. We'll look at it on page 355.
• Although kernel PPP is more efficient, it’s also frequently more difficult to debug. As a result, FreeBSD also supplies an implementation known as user PPP or iijppp, after the Internet Institute of Japan, which supplied the original base code. It uses the tunnel driver to pass IP packets up to a user process. It’s easier to configure and debug, and though it’s not as efficient, the difference is not usually a problem. We'll look at this implementation on page 348.

If you have a DSL link, you don’t have a choice of version: currently, only User PPP supports PPPoE.

Quick setup

The following sections go into some detail about how PPP works. It’s not completely necessary to know it all to set up PPP. If you’re in a hurry, you can move onto the configuration summaries on page 348 for user PPP, or page 359 for kernel PPP.

How PPP works

The following steps are necessary to set up a PPP connection:

• Set up a serial connection between the two systems. This could be a direct wire connection, but normally it’s dialup modem or an ISDN or DSL link.
• For modem link, establish connection, traditionally called dialing the other end. The modems then set up a link and assert DCD (Data Carrier Detect) to tell the machines to which they are connected that the modem connection has been established.
• Start PPP. PPP selects a network interface to use for this connection.
• The two PPP processes negotiate details like IP address, protocol, and authentication protocols.
• Establish routes to the systems at the other end of the link. On the following pages, we'll look at these points in detail.

The interfaces

Most network interfaces are dedicated to networking. For example, an Ethernet adapter can't be used for anything else. Serial lines are different: you could also use them to connect a mouse or even remote terminal. There’s another difference, too: you access serial lines via their device names. You access network interfaces via the ifconfig program, because they don't usually have device names - in technical jargon, they're in a separate name space from files. How do we solve this conflict?

The solution may seem a little surprising: PPP uses two different devices for each connection. You decide which serial line you want to use, and the software chooses a network interface for you, though you can override this choice if you're using user PPP. For example, your serial line might be called /dev/cuaa0, /dev/cuaal or /dev/cuaa2, while your interface will be called tun0 or tun1 (for user PPP), or ppp0 or ppp1 (for kernel PPP). It’s possible to connect to a DSL line without PPP, but when you use PPPoE, you also have two devices, the Ethernet interface and tunO (Kernel PPP does not support PPPoE).

The tunnel device uses a device interface called /dev/ton, where n is a digit, to read and write to the other side of the corresponding network interface.

User PPP runs in user space, so it does require a device name for the network interface, for example tun0. It uses this device to read and write to the back end of the tunnel interface.

Dialing

If you're running a PPP connection over a dial-up link, you'll need to establish a telephone connection, which is still called dialing. That’s modem function, of course, and it’s not defined in the PPP standard.

User PPP includes both built-in dialing support and external dialing support, while kernel PPP supplies only the latter. In practice, the only difference is the way your configuration files look. We’ll look at these when we discuss the individual implementations.

You don't need to dial for a DSL connection.

Negotiation

Once the connection is established and the PPP processes can talk to each other, they negotiate what PPP features they will use.^{1 Years ago, you might have first have had to perform a normal UNIX login ("login authentication"). This was usually handled by the dialing script ("chat script"). Microsoft didn't support this kind of authentication, so it's practically obsolete now, though there's nothing wrong with the idea.} The negotiation is successful if the two sides can agree on a functional subset of the features both would like to have.

For each feature of the link, PPP negotiation can perform up to two actions. User PPP uses the following terms to describe them, viewed from the local end of a link:

• To enable a feature means: "request this feature. "
• To disable a feature means: "do not request this feature. "
• To accept a feature means: "if the other side requests this feature, use it. "
• To deny a feature means: "if the other side requests this feature, refuse it. " Negotiation is successful if each end accepts all the features that the other end has enabled. In some cases, however, PPP systems have an alternative. For example, if you accept PAP and deny CHAP, a router may first request CHAP, and when you deny it, it may then request PAP. You do this by enabling both PAP and CHAP in your PPP configuration files.

Negotiation is successful if each end accepts all the features that the other end has enabled. In some cases, however, PPP systems have an alternative. For example, if you accept PAP and deny CHAP, a router may first request CHAP, and when you deny it, it may then request PAP. You do this by enabling both PAP and CHAP in your PPP configuration files.