Dialing Up with PPP

PPP stands for Point-to-Point Protocol. It is the protocol used for most dial-up Internet connections, and remains in wide use in numerous homes where broadband connectivity (DSL or cable) is not available. If you are among the many users connecting to the Internet through a dial-up modem, you need to know how PPP works in FreeBSD and how you can make it work with as little hassle as possible.

Gathering Necessary Information

After you have signed up with an ISP, you will need to get several pieces of information:

• The communications port that your modem is on. If you have used your computer under Windows and know the COM port to which the modem is connected, the following FreeBSD devices correspond to the DOS COM ports: COM1: cuad0, COM2: cuad1, COM3: cuad2, and COM4: cuad3.

• The IP addresses of your ISP's DNS servers. These are used to resolve domain names to numerical IP addresses.

• Your ISP's dial-up phone number.

• Your username and password.

• The type of authentication your ISP uses. This should be either a standard shell login, Password Authentication Protocol (PAP), or Challenge Handshake Protocol (CHAP). These different authentication protocols will be discussed further later in the chapter.

• Whether you have a static IP address or a dynamic IP address. If you have a static IP address, you will need to know your assigned IP number.

All the information items except the first one can be obtained from your ISP.

User PPP and Kernel PPP

The two types of PPP available with FreeBSD are user PPP and kernel PPP. Both have their advantages and disadvantages. Kernel PPP must be set up by the root user, and support for it must be compiled into the kernel (it's built into the GENERIC kernel). Because it involves a daemon process that handles on-demand connections to the ISP, kernel PPP can be very efficient and seamless in operation. User PPP, however, is a scheme that exists at the user level; support for PPP need not be compiled into the kernel, so the root user does not have to be involved beyond making sure user PPP can be run in the first place. (This can be useful if you are not the administrator of the FreeBSD machine but need to use PPP anyway.) User PPP is somewhat easier to debug than kernel PPP, but because it uses a tunnel devicea type of "virtual network interface" that encapsulates specialized traffic inside a more generic transmission protocolit can be somewhat less efficient than kernel PPP.

This book covers kernel PPP, the more common style used in FreeBSD today. If you only have user access to a FreeBSD machine and you need to dial out using PPP, you'll want to read up on user PPP in the online Handbook: http://www.freebsd.org/handbook/userppp.html.

Configuring the Kernel PPP Daemon

Kernel PPP is handled by the pppd daemon. The main configuration files for pppd will be located in /etc/ppp, though they're not present in the default FreeBSD installation; you'll need to create a few files there, as discussed next, and also modify the /etc/resolv.conf file.

Note

The /etc/ppp/ppp.conf file is used in user PPP, not kernel PPP; you can ignore it unless you're using user PPP.

/etc/resolv.conf

The /etc/resolv.conf file, as you learned in Chapter 23, "Configuring Basic Networking Services," is FreeBSD's Domain Name Server (DNS) configuration fileit determines how FreeBSD resolves remote hostnames to numerical IP addresses. Each line in resolv.conf contains the keyword nameserver followed by the IP address of a DNS server (or nameserver). Nameservers are queried in the order they are listed in the file; if the first nameserver does not respond or does not contain the requested information, the next listed server is checked. An additional useful keyword, domain, allows you to specify the domain name of your system or network. If the domain keyword is present, FreeBSD assumes that any unqualified hostnames (hostnames that do not have a domain after them) are located in the domain specified after the domain keyword. Here is an example of an /etc/resolv.conf file:

domain example.com nameserver 111.111.11.1 nameserver 222.222.22.2

You can edit the /etc/resolv.conf file with any text editor. You will need to be logged in as root to do so.

/etc/ppp/options

The /etc/ppp/options file, which does not exist by default, is where most of the runtime options for the PPP daemon go. It is read before any command-line options that you specify when invoking pppd, so you can override options specified in the file by using the command line.

The contents of the options file are used to specify modem baud rates, handshaking options, routing and domain information, and connection scripts. It is possible to use kernel PPP without an options file because all the potential options have default values; however, you will most likely need to create this file and add a few basic configuration lines specific to your modem and ISP setup. The options that need to go in this file differ depending on the type of authentication your ISP uses. Here is a sample file for using simple shell login authentication and a dynamic IP address (the PAP and CHAP authentication methods are covered in detail in the next sections of this chapter):

/dev/cuad0 115200 crtscts modem connect "/usr/bin/chat -f /etc/ppp/chat.script" noipdefault silent domain example.com defaultroute

Note

Line breaks are not important in the options file; they're there only to aid readability. Otherwise you could put every option and argument on a single line.

Here is what each of the options listed here mean:

• /dev/cuad0 This line sets the device that the modem is located on. In this case, this is equivalent to DOS' COM1. It also sets the port speed to 115,200 bits per second (most dial-up providers won't be able to provide more than 56Kbps, or 57,600 bps).

• crtscts This line sets the hardware flow control of the modem to on. Hardware flow control is required for high-speed communications. Use nocrtscts instead if your modem doesn't use hardware flow control.

• modem This tells pppd to use the modem control lines, wait for a carrier signal before opening the serial port, and other modem-centric behavior. It's not necessary to specify this option (it's on by default), but its opposite is the local option.

• connect This specifies the dialer program to run along with the script that should be used. The chat program can be used to automate the modem connection with a "connect script," specified with the f switch. This will be covered more in the next section.

• noipdefault Use this option if you have a dynamic IP address (your ISP assigns you an IP address each time you log on). This option tells pppd to get an IP address and gateway address from the dial-up server. If you omit this option and don't specify a static address, pppd TRies to figure out the local IP address from your system's hostname, which can confuse the remote server's attempts to assign a dynamic IP address.

• silent This tells pppd to wait for Link Control Protocol (LCP) packets, rather than sending out its own to initiate a connection.

• domain The domain name of your ISP should go here and may be used for authentication purposes. It appends the domain name onto the end of local hostnames.

• defaultroute This will add a routing entry to the system routing tables while pppd is running. When pppd is terminated, the route will be removed.

If you have a static IP address, remove the line that reads noipdefault and replace it with a line that looks like the following:

10.0.0.1:10.0.0.2

Replace the first number before the colon with the IP address your ISP has assigned you. The number after the colon is the gateway address that your ISP has given you. If your ISP has not given you a gateway address, you can leave the second number off (you should include the trailing colon, however). Leaving the gateway address blank, or using the noipdefault option, tells FreeBSD to use the gateway address sent by the ISP during the connection setup process.

These are just a few of the many connection options you can tune in /etc/ppp/options. See the man pppd page for an exhaustive list of these options and what they can do to help you cope with a variety of different kinds of PPP server behaviors.

Tip

If you installed FreeBSD on an ancient system (such as a 486) and you have an external modem, you may find that the preceding setup produces strange resultsconnection resets, stalled transfers, and so on. This is because older systems did not ship with high-speed UART communication chips and might not be able to handle a port speed of 115200. If you get unpredictable performance, try reducing the port speed (specified in the /dev/cuad0 line in /etc/ppp/options) to 57600.

The Chat Script

The pppd daemon has no built-in dialing capabilities. Dialing, rather, is handled externally by the chat program, which allows for an automated (scripted) conversation with the modem. It uses an "expect/send" syntax; in other words, the script contains the format of the prompt to expect from the server, followed by the commands it should send in response, then the next command to expect, and so on.

Here is a sample chat script. You may need to modify this script slightly to work with your particular modem, but this one should get you started. As root, open a new file in any text editor (our example uses a script file saved under the name chat.script in the /etc/ppp directory) and enter the following, all on one line:

[View full width]
ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT5551212 CONNECT "" TIMEOUT 10 ogin:-\\r-ogin:  yourname TIMEOUT 5 sword: yourpassword

This chat script can be broken down into the following component commands:

• ABORT BUSY ABORT 'NO CARRIER' Tells the script to abort if the modem should respond with either BUSY or NO CARRIER.

• AT OK ATDT5551212 CONNECT An ATTENTION signal, which waits for the modem to respond with OK. When it does, the script uses ATDT (Attention Dial Tone) and dials the phone number in the script (555-1212). The script then waits for the modem to send the CONNECT signal.

• Timeout 10 Sets the timeout (the time it waits for the expected string from the server) to 10 seconds.

• ogin:-\\r-ogin: yourname TIMEOUT 5 sword: yourpassword Waits for the string ogin: (which matches either login: or Login:whichever the server happens to send, just to be safe) from the modem; this string represents the login prompt sent by the ISP. After the script has received the login prompt, it responds with yourname, which should be replaced with your ISP login name.

If the login prompt has not been received within 10 seconds, the script aborts. Assuming the script does receive the login prompt and sends the login name, the timer is then reset to five seconds, and the script waits for that length of time to receive sword: (another shortened string, designed to match the ISP's password: or Password: prompt). When the script receives the password, it sends yourpassword, which should be replaced with the password you use to log in to your ISP. After the password has been sent, if your ISP's server automatically changes to PPP mode, the script is done. If, instead, you are put into a login shell, find out from your ISP what shell command needs to be issued to start PPP. Then, you can simply add this command at the end of the script.

Tip

If you are unsure about what prompt syntax your ISP issues, use a terminal emulator such as minicom (available in the ports tree, at /usr/ports/comms/minicom) to dial your ISP's phone number and then perform a manual login. This will enable you to observe what prompts the ISP's server sends when requesting various items of information and update your chat script accordingly.

Caution

If you want to allow non-root users to start the pppd daemon, the chat.script file must be "world readable." A world-readable chat.script file can be a security hazard because anyone with a shell account on your system can get your Internet password from this file. It is much better to use CHAP or PAP authentication if you want normal users to be able to start pppd. The chap-secrets and pap-secrets files (discussed in a later section) need to be readable only by root, even if you are allowing normal users to start pppd. Also, if you do not want the rest of the world to be able to get your Internet password, don't forget to change the permissions on the chat.script file accordingly.

If your ISP supports your having a dial-up password that's different from your email password, you don't have to worry about the plain text chat.script file, because the password it contains isn't really "sensitive information."

Starting the pppd Daemon

After you have completed the preceding tasks, the PPP connection should be ready to go. Simply type pppd at the command prompt to bring it up. If all goes well, your modem should dial and connect. If you have problems, see the troubleshooting section at the end of this chapter.

To stop the pppd daemon, you can either find its PID number with ps and then issue a kill command, or you can use killall, like this:

# killall pppd

Caution

Be careful with the killall command; its behavior on other UNIX systems can be different from its FreeBSD behavior. On Solaris, for instance, it kills every running process.

PAP and CHAP Authentication

Most ISPs these days support the Password Authentication Protocol (PAP) or the Challenge-Handshake Authentication Protocol (CHAP), and somein a world where shell access is less and less commonly offeredsupport only PAP or CHAP. Both of these types of authentication start a PPP session immediately after login, instead of starting up a shell on the server side (as older PPP dial-up mechanisms used to do). This quick startup makes PAP and CHAP a little bit more efficient than a shell login.

PAP and CHAP also have one other advantage over the shell login. The chat script has to be world-readable if you want any users other than root to be able to start pppd. If you use the chat script with the shell login, your password in the chat script is visible to everyone who has access to the system. With PAP and CHAP, the files that contain the passwords do not have to be world-readable, so they are more secure for a multiuser system.

PAP/CHAP requires some extra modifications in the options file and the creation of one or more additional configuration files where your login information is stored. Let's start with the PPP options file. At least one line will need to be added to /etc/ppp/options to determine what profile to use for logging in (you learn more about the profile in "Running Commands on Connect and Disconnect," later in this chapter).

At the end of the options file, add a user line. This line corresponds to a profile name (the profiles will be added later in a different file). The user line looks like this:

user yourname

Replace yourname with the login name you use to log on to your ISP. The following is a list of other options you might need to include:

• refuse-chap If this statement exists in /etc/ppp/options, pppd will refuse to authenticate using CHAP, even if the remote host requests it.

• refuse-pap Like refuse-chap, except it applies to PAP instead.

• require-chap If this option exists in /etc/ppp/options, pppd will require the remote host to authenticate itself using CHAP. Because your ISP's server likely does not authenticate itself to you, you will probably not use this line.

• require-pap Like require-chap, except that it applies to PAP instead.

If you do not include either the refuse-chap or refuse-pap statement in your options file, pppd will accept whichever authentication mechanism the ISP offers first. Note also that if you reject both PAP and CHAP, the connection fails because your system does not have a way to authenticate itself to the ISP.

pap-secrets and chap-secrets

The /etc/ppp/chap-secrets and /etc/ppp/pap-secrets files contain the CHAP and PAP authentication information, respectively. The single line of each file's contents follows the basic format of username hostname password where username is your ISP login name, hostname is the name of the host that this entry will also authenticate, and password is (of course) your dial-up account password. You can replace the hostname entry with a wildcard (*), which tells pppd that this entry can authenticate to any host. Using a wildcard is a good idea for configuring your Internet account, because if you dial in to your ISP, you are already assured that the host you are contacting is who it claims to be. A sample entry for either of these files might look like this:

yourname * yourpassword

Here, yourname is the username, * means that this entry is good for any host, and yourpassword is the password.

You can use other options in the chap-secrets and pap-secrets files, but they are generally used only if you are providing dial-in PPP service. If you are interested, further information on how to use these files can be found in the "Authentication" section of the man pppd page.

Caution

The /etc/ppp/chap-secrets and /etc/ppp/pap-secrets files should be readable only by root. Change the permissions accordingly; otherwise, anyone who has shell access to your system can get your Internet password from these files.

Dial-On-Demand and Persistent Connections

As the name suggests, dial-on-demand means that pppd automatically dials out whenever it detects outgoing traffic that needs to be sent. A persistent connection, on the other hand, is always "up" and redials the connection immediately if pppd detects a disconnect. The following subsections describe how to enable both kinds of connections in kernel PPP.

Dial-On-Demand

Dial-on-demand causes pppd to establish a dial-up connection any time it detects outgoing network traffic when the connection is not already up. The relevant statements in /etc/ppp/options are as follows:

• demand This statement turns on dial-on-demand.

• idle n Here, n is a number representing seconds. This option causes pppd to automatically disconnect after n seconds of being idle, meaning that no traffic has been sent or received over the PPP link during that time.

After you have enabled dial-on-demand, you can create a startup script to automatically start the pppd daemon each time your system boots. There are several ways to do this; but, as you have seen in Chapter 14, "System Configuration and Startup Scripts," the best way is to create a startup script in /usr/local/etc/rc.d with the single line pppd in it. This file can be called anything you want, but it's a good idea to name it ppp (which succinctly suggests what it's for).

Tip

If you have dial-on-demand enabled and your modem keeps inexplicably dialing every now and then, a program is probably trying to do a DNS lookup. More often than not, Sendmail is the program causing problems. You can fix this by enabling the SMART_HOST relay definition or the nodns feature in the freebsd.mc configuration file, or by adding the IP address and hostname of your ISP's mail server to your /etc/hosts file. See Chapter 25, "Configuring Email Services," for information on how to configure Sendmail using the Master Config file.

Tip

If you have dial-on-demand enabled and you are running Fetchmail in daemon mode so that it periodically polls your mail server, this might keep the connection open all the time in addition to causing pppd to dial on a regular basis. See the "Email for Standalone Workstations" section in Chapter 25 for ways to stop this from happening.

Persistent Connections

You can also tell pppd to always keep the connection up. This is done by adding the persist statement to /etc/ppp/options. If this statement is present, pppd automatically tells the modem to reestablish the connection if it is lost.

Caution

Even if your ISP tells you that you have unlimited access, make sure you read the fine printthere might be a "within reason" clause or something, and it's seldom considered "within reason" to use up an ISP's modem slot at all times unless you have explicit arrangements for it. If you are using the persist option to keep your Internet connection open 24 hours a day, 365 days a year, your ISP may require you to purchase a dedicated line.

Running Commands on Connect and Disconnect

When pppd establishes a connection, it checks for the existence of a script file called ipup in /etc/ppp. Likewise, when the PPP connection goes down, pppd checks for the existence of a file called ip-down in /etc/ppp. If these files exist, whatever commands are listed in them are executed.

Running commands on connect or disconnect can be helpful if, for example, you are running FreeBSD on your laptop while traveling. You could read and respond to email while on a plane. Then when you get to your destination and dial in to your network, you could have pppd flush the mail queue (deliver all the mail you wrote on the plane), as well as running the Fetchmail program to download any new mail you had received. If you put the command to perform these options in /etc/ppp/ip-up, they will automatically be performed when you type pppd to start your dial-up connection. You could then have the ip-down script automatically kill Fetchmail if it is running in daemon mode so that it does not attempt to retrieve mail when the connection is not available.

A sample ip-up script could contain the following:

fetchmail mail.myisp.com apachectl start cd /etc/mail; make start

Similarly, ip-down could contain the following lines:

apachectl stop cd /etc/mail; make stop