PPP for Linux

pppd for Linux is available at ftp://cs.anu.edu.au/pub/software/ppp/.

The Linux kernel sources (2.2 and 2.4) have the necessary drivers for kernel support, and the PPP package contains the user daemon, supplemental programs, documentation, and example configuration files. (If MP support is needed, then kernel 2.4 is also needed.)

Most Linux distributions provide PPP support directly, or it is normally easily added with a package manager or sys admin tool; however, it is important to know how the standard pppd package works considering it is the basis for most distributions. An understanding of the package will help troubleshoot networking problems and the pppd wrappers that have become popular with most distributions.

Should the kernel need to be compiled, the serial and PPP support should be activated.

Compiling

Compiling pppd is very straightforward under Linux:

Place the ppp distribution downloaded from ftp://cs.anu.edu.au/pub/software/ppp/ into a source directory such as /usr/src/.

Unzip the archive:

[root@lefty src]# gunzip ppp-2.4.1.tar.gz 

And untar the tarball:

[root@lefty src]# tar xvf ppp-2.4.1.tar 

This will create the source directory structure ppp-2.4.1. Move into the directory to compile the source code and install pppd:

[root@lefty src]# cd /usr/src/ppp-2.4.1 

Execute the configure script:

[root@lefty ppp-2.4.1]# ./configure 

Then run the make:

[root@lefty ppp-2.4.1]# make 

Finally, install the distribution with make install :

[root@lefty ppp-2.4.1]# make install 

File Location and Configuration

The installation will install files into two directories: /usr/sbin/ and /etc/ppp/.

The files stored in /usr/sbin/ are pppd, the PPP daemon; pppdump, a packet dump utility; and pppstats, a utility that reports the statistics for a given PPP interface.

The files stored in /etc/ppp/ from the installation are chap-secrets and papsecrets, which contain user and authentication information; ip-up and ip-down, which are interface scripts; and options, which defines the behavior of pppd.

pppd supports 100+ options, guaranteeing interoperability with almost any implementation of PPP. Thankfully, most current generations of PPP support the standards requirements that options be negotiated. So many options are not required. However, some of the more common options are given in Table 7.4.

Running pppd

pppd can be used to initiate a connection to a remote site or to wait on a connection from a remote site. When pppd is used to connect to a remote site, it is referred to as client operation, and when used to listen for a connection, it is referred to as the server. (Remember, this client/server model comes from the idea that a client initiates a session; from a protocol perspective, the two nodes are peers and not client and server.)

To initiate a PPP connection using pppd, several configuration options must be known and entered into the pppd configuration files. The following example is one that is typical for a connection to an ISP.

The configuration information needed is the PAP username and password or CHAP host name and password, the access telephone number, whether the IP address is assigned dynamically or statically, and the serial port to which the modem is connected.

Let’s assume the following information for the configuration:

This information must now be entered into the appropriate files. Because this configuration uses PAP authentication, the /etc/ppp/pap-secrets would have the following entry:

#Secrets for authentication using PAP 
# client        server  secret                  IP addresses 
customer1       isp     customerpassword 

The pppd does not provide direct-dial support, so an additional program is needed to dial. The chat program is normally used for this purpose. The chat program makes use of a chat script that, in the past, has played a very important role with remote access servers that required a login session to be initiated before PPP could be started. This is no longer the case with most remote access services—the majority can now start PPP immediately after the modem has picked up.

Nowadays, the chat program, for most ISP and enterprise connections, must only send any needed initialization strings to the modem and the dial command.The chat setting will be specified with the connect parameter. The connect parameter and a few other key parameters are included in the /etc/ppp/options file:

lock 
debug 
/dev/ttyS0 
crtscts 
defaultroute 
connect '/usr/sbin/chat -v " " ATZ OK ATDT 8005555555' 

The options were covered in Table 7.4, but briefly, the options file has defined that pppd needs to lock the serial port (lock option), log extra debug information (debug), use serial port /dev/ttyS0, turn on hardware flow control (crtscts), create a default route to the peer, and then connect using the chat command given.

The connection to the ISP can then be started by simply starting pppd:

[root@lefty /root]# pppd 

Problems with pppd are generally either modem or authentication related.The first place to check for problems is the /var/log/messages file. For example, the following entries:

Jun 3 09:08:45 lefty pppd[11857]: pppd 2.4.1 started by root, uid 0 
Jun 3 09:08:45 lefty pppd[11857]: Removed stale lock on ttyS0 (pid 11850) 
Jun 3 09:08:46 lefty chat[11858]: expect ( ) 
Jun 3 09:09:31 lefty chat[11858]: alarm 
Jun 3 09:09:31 lefty chat[11858]: Failed 
Jun 3 09:09:31 lefty pppd[11857]: Connect script failed 
Jun 3 09:09:32 lefty pppd[11857]: Exit. 

would imply that the chat script failed, which can be caused by a typo or, in this case, the modem not responding.

The easiest way to test the modem is to run a chat script directly and turn up the volume to receive audio feedback from the script:

/usr/sbin/chat -v " " ATZ OK ATL2M2 ATDT 8005555555 

With authentication problems, should the Linux router not be authenticated to the remote site, it will record “Failed to authenticate ourselves to peer.” Should the remote site not authenticate with the Linux node, then Linux will report “Authentication failed.”

Additional Network Services Considerations

For Linux routers acting as gateways, the network designer must determine what additional services should be run on the gateway. The additional services are based on need, expense, and management.

Email

Mail services are often run on the Linux gateway to provide mail delivery, especially to the Internet.

Linux does a very nice job of handling mail services, which might prove to be an ideal solution for a corporate mail system.

Gateways to the Internet should be considered carefully. Placing the mail server on the pppd server leaves the mail server open should the gateway be compromised.

Domain Name Services (DNS)

DNS is often a good candidate for running on the same gateway as pppd. Like a mail server, the DNS server (usually BIND), also is open to attack; however, DNS is not considered as risky as email for several reasons: It is less interesting to hackers, traditionally has fewer holes than mail servers (although this trend is subsiding as mail servers are continually being hardened), and typically only brings about a denial of service as opposed to a threat to resources.

A DNS server run in cache-only mode can be useful for both corporate and Internet gateways. A cache-only server simply caches all entries requested for later use. This saves query time for the next user that requests the particular host name and keeps the additional traffic off the gateway’s WAN link.

For corporate gateways, it is worth considering loading the internal domains on the name server as well. This allows name server resolution to occur locally, as opposed to sending the request over the WAN link. There is a small additional load created by the name server pulling the zones on a timed basis, but the load is typically small and is often worth the trade-off if more than a few internal name resolution requests are required.

Placing a DNS server does have risks, though; and, like email, should be considered carefully to ensure that the advantages gained are worth the risk.

Web Caching

Web caching, like DNS, might be considered for both Internet and corporate connections. Under best circumstances, a 5%-10% hit rate can be expected on visited pages in larger sites. Many current web caching solutions allow predefined sites to be cached and common pages to be “mirrored,” which can be very effective for storing local copies of corporate intranet sites.