Опубликован: 06.08.2012 | Доступ: свободный | Студентов: 1179 / 25 | Оценка: 5.00 / 5.00 | Длительность: 53:41:00
Лекция 20:

Configuring PPP

Actions on connect and disconnect

If you don’t have a permanent connection, there are some things that you might like to do every time you connect, like flush your outgoing mail queue. User PPP provides a method for doing this: create a /etc/ppp/ppp. linkup with the same format as /etc/ppp/ppp.conf. If it exists, PPP looks for the profile you used to start PPP (papchap in our examples) and executes the commands in that section. Use the exclamation mark (!) to specify that the commands should be performed by a shell. For example, to flush your mail queue, you might write:

papchap: !send mail -q

Similarly, you can create a file /etc/ppp/ppp.linkdown with commands to be executed when the link goes down. You can find sample files in the directory /usr/share/examples/ppp.

If things go wrong

Things don’t always work " out of the box. " You could run into a number of problems. We’ll look at the more common ones on page 361.

Setting up kernel PPP

It makes more sense to run PPP in the kernel than in user space: in the kernel it's more efficient and theoretically less prone to error. The implementation has fewer features than user PPP, and it’s not quite as easy to debug, so it is not used as much.

The configuration files for kernel PPP are in the same directory as the user PPP configuration files. You can also set up your own ?/.ppprc file, though I don't recommend this: PPP is a system function and should not be manipulated at the user level.

Kernel PPP uses a daemon called pppd to monitor the line when it is active. Kernel PPP interface names start with ppp followed by a number. You need one for each concurrent link. You don’t need to specifically build a kernel for the ppp interface: FreeBSD Release 5 loads the PPP module /boot/kernel/if_ppp.ko dynamically and adds interfaces as required. This also means that you can no longer check for ppp support with the ifconfig command. The interface won't bet here until you need it.

Kernel PPP used to provide a number of build options to enable some features, including the compression options described below. The options are still there, but they're set by default, so you don’t need to do anything there either.

When kernel PPP starts, it reads its configuration from the file /etc/ppp/options. Here is a typical example:

#Options file for PPPD
defaultroute     set the default route here when the line comes up
crtscts          use hard ware flow control
modem            use modem control lines
deflate 12, 12   use deflate compression
predictorl       use predictor 1 compression
vj-max-slots 16  Van Jacobson compression slots
user FREEBIE     our name (index in password file)
lock             create a UUCP lock file

This is quite a short file, but it’s full of interesting stuff:

  • The defaultroute line tells the kernel PPP to set the default route via this interface after it establishes a connection.
  • The crtscts line tells it to use hardware flow control (necessary to prevent loss of characters). You could also specify xonxoff, which uses software flow control, but hardware flow control is preferable.
  • The modem line says to monitor the modem DCD (Carrier detect) line. If the connection is lost without proper negotiation, the only way that kernel PPP can know about it is because of the drop in DCD.
  • The line deflate tells kernel PPP to request deflate compression, which can increase the effective bandwidth.
  • predictor1 tells PPP to use Predictor1 compression where possible.
  • vj-max-slots specifies how many slots to use for Van Jacobson header compression. Having more slots can speed things up.
  • The user line tells kernel PPP the user ID to use. If you don’t specify this, it takes the system’s name.
  • lock tells kernel PPP to create a UUCP-style lock on the serial line. This prevents other programs, such as getty, from trying to open the line while it is running PPP.

None of these options are required to run pppd, though you'll probably need a user entry to establish connection. It’s good idea to set the indicated options, however.


We've seen that /etc/ppp/options contains a user name, but no password. The passwords are stored in separate files, /etc/ppp/chap-secrets for CHAP, or /etc/ppp/pap-secrets for PAP . The format of either file is:

username systemname password

To match any system name, set systemname to *. For example, to authenticate the FREEBIE we saw on page 351, we would enter the following in the file:

FREEBIE * X4dWg9327

In addition, you should add a domain line to specify your domain for authentication purposes:

domain example.org


Kernel PPP does not perform dialing, so you need to start a program that does the dialing. In the following example, we use chat, a program derived from UUCP intended exactly for this purpose. Some people use kermit, which is in fact a complete communications program for a PC protocol, to perform this function, but this requires manual intervention. chat does the whole job for you.

Chat scripts

chat uses a chat script to define the functions to perform when establishing a connection. See the man page chat(8) for further details. The chat script consists primarily of alternate expect strings, which chat waits to receive, followed by send strings, which chat sends when it receives the expect string.

In addition to these strings, the chat script can contain other commands. To confuse things, they are frequently written on a single line, though this is not necessary: chat does not pay any attention to line breaks. Our chat script, which we store in /etc/ppp/dial. chat, looks more intelligible written in the following manner:

#Abort the chat script if the modem replies BUSY or NO CARRIER
#Wait up to 5 seconds for the reply to each of these
OK ATDT1234567
#Wait 40 seconds for connection

This script first tells chat to abort dial-up on a BUSY or NO CARRIER response from the modem. The next line waits for nothing (") and resets the modem with the command ATZ. The following line waits for the modem to reply with OK, and dials the ISP.

Call setup can take awhile, almost always more than five seconds for real (analogue) modems, so we need to extend the timeout, in this case to 40 seconds. During this time we must get the reply CONNECT from the modem.

Who throws the first stone?

On page 342 we saw how to specify whether we should start negotiating or whether we should wait for the other end to start. By default, kernel PPP starts negotiation. If you want the other end to start, add the keyword passive in your /etc/ppp/options file.

Владимир Шишкин
Владимир Шишкин
Россия, Киров
Олег Страхов
Олег Страхов