Configuring PPP

Dynamic IP configuration

By default, kernel PPP performs dynamic address negotiation, so you don’t need to do anything special for dynamic IP. If you have static addresses, add the following line to /etc/ppp/conf:

139.130.136.133:139.130.136.129

These are the addresses that you would use on machine gw.example.org to set up the PPP link in the middle of Figure 16-7 on page 294. The first address is the local end of the link (the address of the pppn device), and the second is the address of the remote machine (free-gw.example.net).

Running kernel PPP

To run pppd, enter:

# pppd /dev/cuaal 115200 connect 'chat -f /etc/ppp/dial. chat'

This starts kernel PPP on the serial line /dev/cuaal at 115, 200 bps. The option connect tells kernel PPP that the following argument is the name of a program to execute: it runs chat with the options -f /etc/ppp/dial.chat, which tells chat the name of the chat file.

After you run pppd with these arguments, the modem starts dialing and then negotiates a connection with your provider, which should complete within 30 seconds. During negotiation, you can observe progress with the ifconfig command:

$ if config ppp0
ppp0:  flags=8010<POINTOPOINT, MULTICAST> mtu 1500
     at this point, the interface has not yet started
$ if config ppp0
ppp0:  flags=8810<POINTOPOINT, RUNNING, MULTICAST> mtu 1500
     now the interface has been started
$ if config ppp0
ppp0:  flags=8811<UP, POINTOPOINT, RUNNING, MULTICAST> mtu 1500
       inet 139.130.136.133 --> 139.130.136.129 netmask 0xffffffff
     now the connection has been established

Automating the process

You can automate connection setup and disconnection in a number of ways:

• If you have a permanent connection, you can tell kernel PPP to stay up all the time. Add the following line to /etc/ppp/options:

  persist
  

  If this option is set, kernel PPP dials immediately and keeps the connection up regardless of whether traffic is passing or not.
• If you want to be able to connect to the Net automatically whenever you have something to say, use the demand option:

  demand
  

  In this case, kernel PPP does not dial immediately. As soon as you attempt to send data to the net, however, it dials automatically. When the line has been idle for the idle timeout period, it disconnects again and waits for more data before dialing.
• Finally, you can start kernel PPP without either of these options. In this case, you are connected immediately. After the idle timeout period, kernel PPP disconnects and exits. If you want to connect again, you must restart the process.

Timeout parameters

A number of options specify when kernel PPP should dial and disconnect:

• The idle parameter tells kernel PPP to disconnect if the line has been idle for the specified number of seconds, and if persist (see above)has not been specified. For example, to disconnect after five minutes, you could add the following line to the /etc/ppp/options file:

  idle 300
  
• The active-filter parameter allows you to specify which packets to count when determining whether the line is idle. See the man page for more details.
• The hold off parameter tells kernel PPP how long to wait before redialing when the line has been disconnected for reasons other than being idle. If the line is disconnected because it was idle, and you have specified demand, it dials as soon as the next valid packet is received.

Configuration summary

To summarize the examples above, we'll show the kernel PPP versions of the user PPP examples on page 348. As before, we assume that the reference network on page 294 uses CHAP authentication, and we have to initiate. The /etc/ppp/options looks like:

#Options file for PPPD
defaultroute                     set the default route here when the line comes up
crtscts                          use hardware flow control
modem                            use modem control lines
domain example.org               specify your domain name
persist                          stay up all the time
deflate 12,12                    use deflate compression
predictorl                       use predictor 1 compression
vj-max-slots 16                  Van Jacobson compression slots
user FREEBIE                     name to present to ISP
139.130.136.133:139.130.136.129  specify IP addresses of link

/etc/ppp/dial.chat is unchanged from the example on page 357:

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

/etc/ppp/chap-secrets contains:

FREEBIE * X4dWg9327

With kernel PPP, there's no need to disable PAP: that happens automatically if it can't find an authentication for FREEBIE in /etc/pap-secrets.

The change for dynamic addressing is even simpler. Remove the line with the IP addresses from the /etc/ppp/options file:

#Options file for PPPD
defaultroute                     set the default route here when the line comes up
crtscts                          use hardware flow control
modem                            use modem control lines
domain example.org               specify your domain name
persist                          stay up all the time
deflate 12,12                    use deflate compression
predictorl                       use predictor 1 compression
vj-max-slots 16                  Van Jacobson compression slots
user FREEBIE                     name to present to ISP

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. We've seen that user PPP provides a method for doing this with the /etc/ppp/ppp.linkup and /etc/ppp/ppp.linkdown files. Kernel PPP supplies similar functionality with /etc/ppp/auth-up and /etc/ppp/auth-down. Both of these files are shell scripts. For example, to flush your mail queue, you might put the following line in /etc/ppp/auth-up:

send mail -q

Things that can go wrong

Setting up PPP used to be a pain. Two things have made it easier than it used to be. Firstly, the widespread adoption of dialup Internet connections has consolidated the procedure, so one size fits nearly everybody. Secondly, the software has had some of the rough edges taken off, so now it al most works out of the box. Still there are a number of things that can go wrong.

Problems establishing a connection

The first thing you need to do is to dial the connection. If you have an external modem, you can follow the process via the indicator LEDs. The following steps occur:

• First, the OH LED ("offhook") goes on, indicating that the modem is dialing. If this doesn’t happen, check the cables and that you're talking to the right device.
• Next you should see a brief Acker of the RD and TD LEDs. If that doesn’t happen, you may also have cable problems, or it could be a problem with the chat script.
• When the CD (or DCD) LED goes on, you have a connection to the remote system. If you don’t get that, check the phone number.
• If you get this far, but you still don’t get a connection, check the system log files. It's most likely to be an authentication failure. See page 353 for an example of the messages from user PPP. Kernel PPP is much less verbose.