The procedures for installing and configuring PPP vary from
implementation to implementation.[61] In this section, we use the PPP daemon implementation
(pppd) included with Linux and the
supporting configuration commands that come with it. PPP is an Internet
standard, and most Unix systems include support for it in the kernel as
part of the standard operating system installation. Usually this does
not require any action on your part. Refer to Chapter 5 for examples of how PPP is
configured in the Linux kernel. The Linux system installs the PPP
physical and data link layer software (the HDLC protocol) in the
kernel.
Installing PPP in the kernel is only the beginning. In this
section, we look at how pppd is used
to provide PPP services on a Linux system.
Point-to-Point Protocol is implemented on the Linux system in the PPP daemon
(pppd), which was derived from a
freeware PPP implementation for BSD systems. pppd can be configured to run in all modes:
as a client, as a server, over dial-up connections, and over dedicated
connections. (Clients and servers are familiar concepts from Chapter 3.) A dedicated connection is a direct cable connection or a
leased line, neither of which requires a telephone to establish the
connection. A dial-up connection is a modem link established by
dialing a telephone number.
Configuring pppd for a
dedicated line is the simplest configuration. A dial-up script is not
needed for a leased line or direct connection. There is no point in
dynamically assigning addresses because a dedicated line always
connects the same two systems. Authentication is of limited use because the dedicated line physically runs between
two points. There is no way for an intruder to access the link, short
of “breaking and entering” or a wiretap. A single pppd command placed in a startup file
configures a dedicated PPP link for our Linux system:
pppd /dev/cua3 56000 crtscts defaultroute
The /dev/cua3 argument selects the device to which PPP is attached.
It is, of course, the same port to which the dedicated line is
attached. Next, the line speed is specified in bits per second
(56000). The remainder of the command line is a series of keyword
options. The crtscts option turns on hardware flow control. The final
option, defaultroute , creates a default route using the remote server as the
default gateway.[62]
PPP exchanges IP addresses during the initial link connection process. If no
address is specified on the pppd
command line, the daemon sends the address of the local host, which it
learns from DNS or the host table, to the remote host. Likewise, the
remote system sends its address to the local host. The addresses are
then used as the source and destination addresses of the link. You can
override this by specifying the addresses on the command line in the
form local-address : remote-address.
For example:
pppd /dev/cua3 56000 crtscts defaultroute 172.16.24.1:
Here we define the local address as 172.16.24.1 and leave the
remote address blank. In this case pppd sends the address from the command line
and waits for the remote server to send its address. The local address
is specified on the command line when it is different from the address
associated with the local hostname in the host table or the DNS
server. For example, the system might have an Ethernet interface that
already has an address assigned. If we want to use a different address
for the PPP connection, we must specify it on the pppd command line; otherwise, the PPP link
will be assigned the same address as the Ethernet interface.
The pppd command has many more options than those used in these
examples (see Appendix A for a full
list of options). In fact, there are so many pppd command-line options that it is
sometimes easier to put them in a file than to enter them all on the
command line. pppd reads its
options from the /etc/ppp/options
file, then the ~/.ppprc file, then the /etc/ppp/options.device file (where device
is a device name like cua3), and finally from the command line. The
order in which they are processed creates a hierarchy such that
options on the command line can override those in the ~/.ppprc file, which can in turn override those in the /etc/ppp/options file. This permits the
system administrator to establish certain systemwide defaults in the
/etc/ppp/options file while still
permitting the end user to customize the PPP configuration. The
/etc/ppp/options file is a
convenient and flexible way to pass parameters to pppd.
A single pppd command is all
that is needed to set up and configure the software for a dedicated
PPP link. Dial-up connections are more challenging.
A direct-connect cable can connect just two systems. When a third system is purchased, it cannot be added to the network. For that reason, most people use expandable network technologies, such as Ethernet, for connecting systems in a local area. Additionally, leased lines are expensive. They are primarily used by large organizations to connect networks of systems. For these reasons, using PPP for dedicated network connections is less common than using it for dial-up connections.
Several different utilities provide dial-up support for PPP.
Dial-up IP (dip
) is a popular package for simplifying the process of
dialing the remote server, performing the login, and attaching PPP to
the resulting connection. We discuss dip in this section because it is popular
and freely available for a wide variety of Unix systems, and because
it comes with Red Hat Linux, which is the system we have been using
for our PPP examples.
One of the most important features of dip is a scripting language that lets you
automate all the steps necessary to set up an operational PPP link.
Appendix A covers all the scripting
commands supported by the 3.3.7o-uri version of dip, which is the version included with Red
Hat. You can list the commands supported by your system by running
dip in test mode (-t) and
then entering the help command:
> dip -t DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96) Written by Fred N. van Kempen, MicroWalt Corporation. DIP> help DIP knows about the following commands: beep bootp break chatkey config databits dec default dial echo flush get goto help if inc init mode modem netmask onexit parity password proxyarp print psend port quit reset send shell sleep speed stopbits term timeout wait DIP> quit
These commands can configure the interface, control the execution of the script, and process errors. Only a subset of the commands is required for a minimal script:
# Ask PPP to provide the local IP address get $local 0.0.0.0 # Select the port and set the line speed port cua1 speed 38400 # Reset the modem and flush the terminal reset flush # Dial the PPP server and wait for the CONNECT response dial *70,301-555-1234 wait CONNECT # Give the server 2 seconds to get ready sleep 2 # Send a carriage-return to wake up the server send \r # Wait for the Login> prompt and send the username wait ogin> send kristin\r # Wait for the Password> prompt and send the password wait word> password # Wait for the PPP server's command-line prompt wait > # Send the command required by the PPP server send ppp enabled\r # Set the interface to PPP mode mode PPP # Exit the script exit
The get command at the beginning of the script allows PPP to
provide the local and remote addresses. $local is a script variable. There are
several available script variables, all of which are covered in Appendix A. $local normally stores the local address,
which can be set statically in the script. A PPP server, however, is
capable of assigning an address to the local system dynamically. We
take advantage of this capability by giving a local address of all 0s.
This peculiar syntax tells dip to
let pppd handle the address
assignments. A pppd client can get
addresses in three ways:
The PPP systems can exchange their local addresses as determined from DNS. This was discussed previously for the dedicated line configuration.
The addresses can be specified on the pppd command line, also discussed
previously.
The client can allow the server to assign both addresses. This feature is most commonly used on dial-up lines. It is very popular with servers that must handle a large number of short-lived connections. A dial-up Internet Service Provider (ISP) is a good example.
The next two lines select the physical device to which the modem
is connected, and set the speed at which the device operates. The
port command assumes the path /dev, so
the full device path is not used. On most PC Unix systems, the value
provided to the port command is
cua0, cua1, cua2, or cua3. These values correspond to MS-DOS ports
COM1 to COM4. The speed command sets the maximum speed used to send data to the
modem on this port. The default speed is 38400. Change it if your
modem accepts data at a different speed.
The reset command resets the modem by sending it the Hayes modem
interrupt (+++) followed by the Hayes modem reset command (ATZ). This
version of dip uses the Hayes modem
AT command set and works only with Hayes-compatible modems.[63] Fortunately, that includes most brands of modems. After
being reset, the modem responds with a message indicating that the
modem is ready to accept input. The flush command removes this message, and any others that might
have been displayed by the modem, from the input queue. Use flush to avoid the problems that can be
caused by unexpected data in the queue.
The next command dials the remote server. The dial command sends a standard Hayes ATD dial command to the modem. It passes the
entire string provided on the command line to the modem as part of the
ATD command. The sample dial
command generates ATD*70,301-555-1234. This causes the modem to dial
*70 (which turns off call waiting[64]), and then area code 301, exchange 555, and number
1234.When this modem successfully connects to the remote modem, it
displays the message CONNECT. The wait command waits for that message from the modem.
The sleep 2 command inserts a two-second delay into the script. It
is often useful to delay at the beginning of the connection to allow
the remote server to initialize. Remember that the CONNECT message is
displayed by the modem, not by the remote server. The remote server
may have several steps to execute before it is ready to accept input.
A small delay can sometimes avoid unexplained intermittent
problems.
The send command sends a carriage return (\r) to the remote
system. Once the modems are connected, anything sent from the local
system goes all the way to the remote system. The send command can send any string. In the
sample script, the remote server requires a carriage return before it
issues its first prompt. The carriage return is entered as \r and the
newline is entered as \n.
The remote server then prompts for the username with Login>. The wait ogin> command detects this prompt, and the send kristin command sends the username kristin as a response. The server then
prompts for the password with Password>. The password command causes the script to prompt the local user to
manually enter the password. It is possible to store the password in a
send command inside the script.
However, this is a potential security problem if an unauthorized
person gains access to the script and reads the password. The password command improves security.
If the password is accepted, our remote server prompts for input
with the greater-than symbol (>). Many servers require a command to
set the correct protocol mode. The server in our example supports
several different protocols. We must tell it to use PPP by using
send to pass it the correct
command.
The script finishes with a few commands that set the correct
environment on the local host. The mode command tells the local host to use the PPP protocol on
this link. The protocol selected must match the protocol running on
the remote server. Protocol values that are valid for the dip mode
command are SLIP, CSLIP, PPP, and TERM. SLIP and CSLIP are variations
of the SLIP protocol, which was discussed earlier. TERM is terminal
emulation mode. PPP is the Point-to-Point Protocol. Finally, the
exit command ends the script, while dip keeps running in the background
servicing the link.
This simple script does work and it should give you a good idea
of the wait/send structure of a dip
script. However, your scripts will probably be more complicated. The
sample script is not robust because it does not do any error checking.
If an expected response does not materialize, the sample script hangs.
To address this problem, use a timeout on each wait command. For example, the wait OK 10 command tells the system to wait
10 seconds for the OK response. When the OK response is detected, the
$errlvl script variable is set to
zero and the script falls through to the next command. If the OK
response is not returned before the 10-second timer expires, $errlvl is set to a nonzero value and the
script continues on to the next command. The $errlvl variable is combined with the
if and goto commands to provide error handling in
dip scripts. Refer to Appendix A for more details.
Once the script is created, it is executed with the dip command. Assume that the sample script shown above was
saved to a file named start-ppp.dip. The
following command executes the script, creating a PPP link between the
local system and the remote server:
> dip start-pppTerminate the PPP connection with the command dip -k. This closes the connection and kills
the background dip process.
pppd options are not
configured in the dip script.
dip creates the PPP connection; it
doesn’t customize pppd. pppd options are stored in the
/etc/ppp/options file.
Assuming the dip script shown
above, we might use the following pppd options:
noipdefault ipcp-accept-local ipcp-accept-remote defaultroute
The noipdefault option tells
the client not to look up the local address. ipcp-accept-local tells the client to obtain
its local address from the remote server. The ipcp-accept-remote option tells the system
to accept the remote address from the remote server. Finally, pppd sets the PPP link as the default route.
This is the same defaultroute
option we saw on the pppd command
line in an earlier example. Any pppd option that can be invoked on the
command line can be put in the /etc/ppp/options
file and thus be invoked when pppd
is started by a dip script.
I use dip on my home computer
to set up my dial-up PPP connection.[65] Personally, I find dip simple and straightforward to use, in
part because I am familiar with the dip scripting language. You may prefer to
use the chat command that comes
with
the pppd software package.
A chat script is a simple expect/send script consisting of the
strings the system expects and the strings it sends in response. The
script is organized as a list of expect/send pairs. chat does not really have a scripting
language, but it does have some special characters that can be used to
create more complex scripts. The chat script to perform the same dial-up and
login functions as the sample dip
script would contain:
'' ATZ OK ATDT*70,301-555-1234 CONNECT \d\d\r ogin> kristin word> Wats?Wat? > 'set port ppp enabled'
Each line in the script begins with an expected string and ends
with the string sent as a response. The modem does not send a string
until it receives a command. The first line in the script says, in
effect, “expect nothing and send the modem a reset command.” The pair
of single quotes ('') at the
beginning of the line tells chat to
expect nothing. The script then waits for the modem’s OK prompt and
dials the remote server. When the modem displays the CONNECT message,
the script delays two seconds (\d\d) and then sends a carriage return
(\r). Each \d special character causes a one-second delay. The \r
special character is the carriage return. chat has many special characters that can be
used in the expect strings and the send strings.[66] Finally, the script ends by sending the username,
password, and remote server configuration command in response to the
server’s prompts.
Create the script with your favorite editor and save it in a
file such as dial-server. Test the script
using chat with the
-V option, which logs the script
execution through stderr:
% chat -V -f dial-serverInvoking the chat script is
not sufficient to configure the PPP line. It must be combined with
pppd to do the whole job. The connect command-line option allows you to start pppd and invoke a dial-up script all in one
command:
# pppd /dev/cua1 56700 connect "chat -V -f dial-server" \ nodetach crtscts modem defaultroute
The chat command following the connect option is used to perform the
dial-up and login. Any package capable of doing the job could be
called here; it doesn’t have to be chat.
The pppd command has some
other options that are used when PPP is run as a dial-up client. The
modem option causes pppd
to monitor the carrier-detect (DCD) indicator of the modem. This
indicator tells pppd when the
connection is made and when the connection is broken. pppd monitors DCD to know when the remote
server hangs up the line. The nodetach option prevents pppd
from detaching from the terminal to run as a background process. This
is necessary only when running chat
with the -V option. When you are
done debugging the chat script, you
can remove the -V option from the
chat subcommand and the nodetach option from the pppd command. An alternative is to use
-v on the chat command. -v does not require pppd to remain attached to a terminal
because it sends the chat logging
information to syslogd instead of
to stderr. We have seen all of the other options on this command line
before.
A major benefit of PPP over SLIP is the enhanced security PPP
provides. Put the following pppd
options in the /etc/ppp/options file to enhance
security:
lock auth usehostname domain wrotethebook.com
The first option, lock, makes pppd use UUCP-style lock files. This
prevents other applications, such as UUCP or a terminal emulator, from
interfering with the PPP connection. The auth option requires the remote system to be authenticated
before the PPP link is established. This option causes the local
system to request authentication data from the remote system. It does
not cause the remote system to request similar data from the local
system. If the remote system administrator wants to authenticate your
system before allowing a connection, she must put the auth keyword in the configuration of her
system. The usehostname option requires that the hostname is used in the
authentication process and prevents the user from setting an arbitrary
name for the local system with the name option. (More on authentication in a
minute.) The final option makes sure that the local hostname is fully
qualified with the specified domain before it is used in any
authentication procedure.
Recall that the ~/.ppprc file and the
pppd command-line options can
override options set in the /etc/ppp/options
file, which could be a security problem. For this reason, several
options, once configured in the /etc/ppp/options
file, cannot be overridden. That includes the options just
listed.
pppd supports two authentication protocols: Challenge Handshake Authentication Protocol (CHAP) and
Password Authentication Protocol (PAP). PAP is a simple
password security system that is vulnerable to all of the attacks of
any reusable password system. CHAP, however, is an advanced
authentication system that does not use reusable passwords and that
repeatedly reauthenticates the remote system.
Two files are used in the authentication process, the
/etc/ppp/chap-secrets file and the /etc/ppp/pap-secrets
file. Given the options file shown above, pppd first attempts to authenticate the
remote system with CHAP. To do this, there must be data in the
chap-secrets file, and the remote system must
respond to the CHAP challenge. If either of these conditions is not
true, pppd attempts to authenticate
the remote system with PAP. If there is no applicable entry in the
pap-secrets file or the remote system does not
respond to the PAP challenge, the PPP connection is not established.
This process allows you to authenticate remote systems with CHAP (the
preferred protocol), if they support it, and to fall back to PAP for
systems that support only PAP. For this to work, however, you must
have the correct entries in both files.
Each entry in the chap-secrets file contains up to four fields:
The name of the computer that must answer the challenge, i.e., the computer that must be authenticated before the connection is made. This is not necessarily a client that is seeking access to a PPP server; although client is the term used in most of the documentation, it is really the respondent—the system that responds to the challenge. Both ends of a PPP link can be forced to undergo authentication. In your chap-secrets file you will probably have two entries for each remote system: one entry to authenticate the remote system, and a corresponding entry to authenticate your system when it is challenged by the remote system.
The name of the system that issues the CHAP challenge, i.e., the computer that requires the authentication before the PPP link is established. This is not necessarily a PPP server. The client system can require the server to authenticate itself. Server is the term used in most documentation, but really this is the authenticator—the system that authenticates the response.
The secret key that is used to encrypt the challenge string before it is sent back to the system that issued the challenge.
An address, written as a hostname or an IP address, that is acceptable for the host named in the first field. If the host listed in the first field attempts to use an address other than the address listed here, the connection is terminated even if the remote host properly encrypts the challenge response. This field is optional.
A sample chap-secrets file for the host ring might contain:
limulus ring Peopledon'tknowyou 172.16.15.3 ring limulus andtrustisajoke. 172.16.15.1
The first entry is used to validate limulus, the remote PPP server. limulus is being authenticated and the system performing the authentication is ring. The secret key is “Peopledon’tknowyou”. The allowable address is 172.16.15.3, which is the address assigned to limulus in the host table. The second entry is used to validate ring when limulus issues the challenge. The secret key is “andtrustisajoke.”. The only address ring is allowed to use is 172.16.15.1. A pair of entries, one for each end of the link, is normal. The chap-secret file usually contains two entries for every PPP link: one for validating the remote system and one for answering the challenge of that remote system.
Use PAP only when you must. If you deal with a system that does not support CHAP, make an entry for that system in the pap-secrets file. The format of pap-secrets entries is the same as those used in the chap-secrets file. A system that does not support CHAP might have the following entry in the pap-secrets file:
24seven ring Wherearethestrong? 24seven.wrotethebook.com ring 24seven Whoarethetrusted? ring.wrotethebook.com
Again we have a pair of entries: one for the remote system and one for our system. We support CHAP but the remote system does not. Thus we must be able to respond using the PAP protocol in case the remote system requests authentication.
PPP authentication improves security in a dial-up environment. It is most important when you run the PPP server into which remote systems dial. In the next section, we look at PPP server configuration.
The PPP server can be started in several different ways. One way
is to use pppd as a login
shell for dial-in PPP users. Replace the login shell entry in the
/etc/passwd file with the path of pppd to start the server. A modified
/etc/passwd entry might contain:
craig:wJxX.iPuPzg:101:100:Craig Hunt:/etc/ppp:/usr/sbin/pppd
The fields are exactly the same as in any
/etc/passwd entry: username, password, uid, gid,
gcos information, home directory, and login shell. For a remote PPP
user, the home directory is /etc/ppp and the
login shell is the full path of the pppd program. The encrypted password must be
set using the passwd program, just
as for any user, and the login process is the same as it is for any
user. When getty detects incoming
traffic on the serial port it invokes login to authenticate the user. login verifies the username and the password
entered by the user and starts the login shell. In this case, the
login shell is actually the PPP daemon.
When the server is started in this manner, server options are
generally placed in the /etc/ppp/.ppprc file.
login validates the user, and
pppd authenticates the client.
Therefore the chap-secrets or
pap-secrets file must be set up to handle the
client system from which this user logs in.
A traditional alternative to using pppd as the login script is to create a real script in which
pppd is only one of the commands.
For example, you might create an
/etc/ppp/ppplogin script such as the
following:
#!/bin/sh mesg -n stty -echo exec /sbin/pppd auth passive crtscts modem
You can see that the script can contain more than just the
pppd command. The mesg -n command makes sure that other users
cannot write to this terminal with talk, write, or similar programs. The stty command turns off character echoing. On
some systems, characters typed at the terminal are echoed from the
remote host instead of being locally echoed by the terminal; this
behavior is called full duplex. We don’t want to
echo anything back on a PPP link, so we turn full duplex off.
Controlling the characteristics of the physical line is the main
reason that pppd is often placed
inside a script file.
The key line in the script is, of course, the line that starts
pppd. We start the daemon with
several options, but one thing that is not included on the command
line is the tty device name. In all of the
previous pppd examples, we provided
a device name. When it is not provided, as is this case, pppd uses the controlling terminal as its
device and doesn’t put itself in background mode. This is just what we
want. We want to use the device that login was servicing when it invoked the
ppplogin script.
The auth command-line option tells pppd to authenticate the remote system,
which of course requires us to place an entry for that system in the
chap-secrets or the
pap-secrets file. The crtscts option turns on hardware flow control, and the modem option tells PPP to monitor the modem’s DCD indicator
so that it can detect when the remote system drops the line. We have
seen all of these options before. The one new option is passive. With passive set, the local system waits until it receives a valid
LCP packet from the remote system, even if the remote system fails to
respond to its first packet. Normally, the local system would drop the
connection if the remote system fails to respond in a timely manner.
This option gives the remote system time to initialize its own PPP
daemon.
A final option for running PPP as a server is to allow the user
to start the server from the shell prompt. To do this, pppd must be installed as setuid root, which
is not the default installation. Once pppd is setuid root, a user with a standard
login account can log in and then issue the following command:
$ pppd proxyarpThis command starts the PPP daemon. Assuming that the auth parameter is set in the
/etc/ppp/options file, pppd authenticates the remote client using
CHAP or PAP. Once the client is authenticated, a proxy ARP entry for
the client is placed in the server’s ARP table so that the client
appears to other systems to be located on the local network.
Of these three approaches, I prefer to create a shell script
that is invoked by login as the
user’s login shell. With this approach, I don’t have to install
pppd setuid root. I don’t have to
place the burden of running pppd on
the user. And I get all the power of the pppd command plus all the power of a shell script.
dip and pppd are available for Linux, BSD, AIX, Ultrix, OSF/1, and
SunOS. If you have a different operating system, you probably won’t
use these packages. Solaris is a good example of a system that uses a
different set of commands to configure PPP.
PPP is implemented under Solaris as the Asynchronous PPP Daemon (aspppd). aspppd is configured by the /etc/asppp.cf
file. The asppp.cf file is divided into two
sections: an ifconfig section and a
path section.
ifconfig ipdptp0 plumb ring limulus up path interface ipdptp0 peer_system_name limulus inactivity_timeout 300
The ifconfig command configures the PPP interface (ipdptp0) as a point-to-point link with a
local address of ring and a destination address
of limulus. The ifconfig command does not have to define the
destination address of the link. However, if you always connect to the
same remote server, it will probably be defined here as the
destination address. We saw all of these options in the discussion of
the ifconfig command earlier in
this chapter.
The more interesting part of this file is the path section, which defines the PPP environment. The
interface statement identifies the
interface used for the connection. It must be one of the PPP
interfaces defined in the ifconfig
section. In the example, only one is defined, so it must be ipdptp0. The peer_system_name statement identifies the
system at the remote end of the connection. This may be the same
address as the destination address from the ifconfig statement, but it doesn’t have to
be. It is possible to have no destination address on the ifconfig command and several path sections if you connect to several
different remote hosts. The hostname on the peer_system_name statement is used in the
dialing process, as described later.
The path section ends with an
inactivity_timeout statement. The command in the sample sets the timeout
to 300 seconds. This points out a nice feature of the Solaris system.
Solaris automatically dials the remote system when it detects data
that needs to be delivered through that system. Further, it
automatically disconnects the PPP link when it is inactive for the
specified time. With this feature you can use a PPP link without
manually initiating the dial program and without tying up phone lines
when the link is not in use.
Like pppd, aspppd does not have a built-in dial
facility. It relies on an external program to do the dialing. In the
case of aspppd, it utilizes the
dial-up facility that comes with UUCP. Here’s how.
First, the serial port, the modem attached to it, and the speed at which they operate are defined in the /etc/uucp/Devices file. For example, here we define an Automatic Call Unit (ACU is another name for a modem) attached to serial port B (cua/b) that operates at any speed defined in the Systems file, and that has the modem characteristics defined by the “hayes” entry in the Dialers file:
ACU cua/b - Any hayes
Next, the modem characteristics, such as its initialization
setting and dial command, are defined in the
/etc/uucp/Dialers file. The initialization and
dial commands are defined as a chat
script using the standard expect/send format and the standard set of
chat special characters. For
example:
hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT
The system comes with Devices and
Dialers preconfigured. The preconfigured entries
are probably compatible with the modem on your system. The
/etc/uucp/Systems file may be the only
configuration file that you modify. In the
Systems file, you need to enter the name of the
remote system, select the modem you’ll use, enter the telephone
number, and enter a chat script to
handle the login. For example:
limulus Any ACU 56700 5551234 "" \r ogin> kristin word> Wats?Watt? > set ppp on
In this one line, we identify limulus as
the remote system, declare that we allow connections to and from that
host at any time of the day (Any), select the ACU entry in the
Devices file to specify the port and modem, set
the line speed to 56700, send the dialer the telephone number, and
define the login chat
script.
This is not a book about UUCP, so we won’t go into further
details about these files. I’d suggest looking at the Solaris
AnswerBook and the Solaris TCP/IP Network Administration Guide (where did they come up with such a great name?) for
more information about UUCP and aspppd.
There are several layers of complexity that make PPP connections difficult to debug. To set up PPP, we must set up the serial port, configure the modem, configure PPP, and configure TCP/IP. A mistake in any one of these layers can cause a problem in another layer. All of these layers can obscure the true cause of a problem. The best way to approach troubleshooting on a serial line is by debugging each layer, one layer at a time. It is usually best to troubleshoot each layer before you move on to configure the next layer.
The physical serial ports should be configured by the system during the system boot. Check the /dev directory to make sure they are configured. On a Linux system with four serial ports, the inbound serial ports are /dev/ttyS0 through /dev/ttyS3 and the outbound serial ports are /dev/cua0 through /dev/cua3. There are many more tty and cua device names. However, the other devices are associated with real physical devices only if you have a multi-port serial card installed in your Linux system. Most Unix systems use the names tty and cua, even if those names are just symbolic links to the real devices. Solaris is a good example:
% ls -l /dev/tty? lrwxrwxrwx 1 root root 6 Sep 23 2001 /dev/ttya -> term/a lrwxrwxrwx 1 root root 6 Sep 23 2001 /dev/ttyb -> term/b % ls -l /dev/cua/* lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/a -> /devices/obio/zs@0,100000:a,cu lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/b -> /devices/obio/zs@0,100000:b,cu
If the serial devices do not show up in the
/dev directory, they can be manually added with a
mknod command. For example, the
following commands create the serial devices for the first serial port
on a Linux system:
# mknod -m 666 /dev/cua0 c 5 64 # mknod -m 666 /dev/ttyS0 c 4 64
However, if you need to add the serial devices manually, there may be a problem with the kernel configuration. The serial devices should be installed in your system by default during the boot when the hardware is detected. The following boot message shows the detection of a single serial interface on a Linux system:
$ dmesg | grep tty
ttyS00 at 0x03f8 (irq = 4) is a 16550You should see similar messages from your system boot for each interface that is detected. If you don’t, you may have a hardware problem with the serial interface board.
The modem used for the connection is attached to one of the
serial ports. Before attempting to build a dial-up script, make sure
the modem works and that you can communicate with it through
the port. Use a simple serial communications package, such as minicom, kermit, or seyon. First, make sure the program is
configured to use your modem. It must be set to the correct port,
speed, parity, number of databits, etc. Check your modem’s
documentation to determine these settings.
We’ll use minicom on a Linux
system for our examples. To configure minicom , su to
root and run it with the -s option, which displays a configuration
menu. Walk through the menu and make sure everything is properly set.
One thing you might notice is that the port is set to
/dev/modem. That device name is sometimes
symbolically linked to the port to which the modem is connected. If
you’re not sure that the link exists on your system, enter the correct
port name in the minicom
configuration, e.g., /dev/cua1. After checking
the configuration, exit the menu and use the minicom terminal emulator to make sure you
can communicate with the modem:
Welcome to minicom 1.83.1 OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n Compiled on Feb 23 2001, 07:31:40. Press CTRL-A Z for help on special keys AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK atz OK atdt555-1234 CONNECT 26400/LAPM-V ^M Enter login> kristin Enter user password> Wats?Watt? Welcome to the PPP MODEM POOL PORT-9> set port ppp enabled +++ OK ath OK atz OK ^A CTRL-A Z for help | 57600 8N1 | NOR | Minicom 1.83.1 | VT102 | Offline X
In the sample, minicom
displays a few header lines and then sends a Hayes command (AT) to the modem. We didn’t set this
command; it was part of the default minicom configuration. (If it causes
problems, edit it out of the configuration using the menus discussed
previously.) We then reset the modem (atz) and dial the remote server (atdt). When the modems connect, we log into
the server and configure it. (The login process is different for every
remote server; this is just an example.) Everything appears to be
running fine, so we end the connection by getting the modem’s
attention (+++), hanging up the
line (ath), and resetting the
modem. Exit minicom by pressing
Ctrl-A followed by X. On our sample system the port and modem are
working. If you cannot send simple commands to your modem, ensure
that:
The modem is properly connected to the port
You have the correct cables
The modem is powered up
The modem is properly configured for dial-out and for echoing commands
When the modem responds to simple commands, use it to dial the
remote server as we did in the example above. If the modem fails to
dial the number or displays the message NO DIALTONE, check that the
telephone line is connected to the correct port of the modem and to
the wall jack. You may need to use an analog phone to test the
telephone wall jack and replace the line between the modem and the
wall to make sure that the cable is good. If the modem dials but fails
to successfully connect to the remote modem, check that the local
modem configuration matches the configuration required by the remote
system. You must know the requirements of that remote system to
successfully debug a connection. See the following list of script
debugging tips for some hints on what to check. If you can
successfully connect to the remote system, note everything you entered
to do so, and note everything that the modem and the remote server
display. Then set the remote server to PPP or SLIP mode and note how
you accomplished this. You will need to duplicate all of these steps
in your dip script.
Start with a bare-bones script, like the sample
start-ppp.dip script, so that you can debug the
basic connection before adding the complexity of error processing to
the script. Run the script through dip using the verbose option (-v) option. This displays each line of the
script as it is processed. Look for the following problems:
The modem does not respond to the script. Check that you are
using the correct device on the port command. Make sure that if the
script contains databits,
parity, speed, or stopbits commands, they are set to
values compatible with your modem. Double-check that the modem is
Hayes-compatible, particularly if you attempt to do modem
configuration using dip
keywords instead of using send.
The modem fails to connect to the remote host. Make sure the
modem is configured exactly as it was during the manual login. The
modem’s databits, parity, and other options need to match the
configuration of the remote system. It is possible that you will
need a special configuration, for example, 7-bit/even-parity, to
perform the login before you can switch to the 8-bit/no-parity
configuration required by PPP and SLIP. Don’t forget to check that
the phone number entered in the dial command is correct, particularly if
the modem displays VOICE, RING - NO ANSWER, or BUSY when you
expect to see CONNECT.
The script hangs. It is probably waiting for a response.
Make sure that the string in each wait command is correct. Remember that
the string only needs to be a subset of the response. It is better
to use the string “>” than it is to use “Port9>” if you are
not sure whether the remote system always displays the same port
number. Use a substring from the end of the expected response so
that the script does not send to the server before the server is
ready for input. Also try putting a delay into the script just
before the script sends the first command to the server, e.g.,
sleep 2 to delay two seconds. A
delay is sometimes needed to allow the server to initialize the
port after the modems connect.
The remote server displays an error message. The script
probably sent an incorrect value. Check the string in each
send command. Make sure they
terminate with the correct carriage-return or line-feed
combination expected by the remote server.
If you have trouble with the script, try running dip in test mode (-t), which allows you to enter each command
manually one at a time. Do this repeatedly until you are positive that
you know all the commands needed to log into the remote server. Then
go back to debugging the script. You’ll probably have fresh insight
into the login process that will help you find the flaw in the
script.
Once the script is running and the connection is successfully
made, things should run smoothly. You should be able to ping the remote server without difficulty.
If you have problems, they may be in the IP interface configuration or
in the default route. The script should have created the serial
interface. The netstat -ni command
shows which interfaces have been configured:
# netstat -ni
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
dnet0 1500 172.16.15.0 172.16.15.1 1 0 4 0 0 0
lo0 1536 127.0.0.0 127.0.0.1 1712 0 1712 0 0 0
ppp0 1006 172.16.15.26 172.16.15.3 0 0 0 0 0 0The interface, ppp0 in the example, has been installed. The
default command in the script
creates a default route. Use netstat to see the contents of the routing
table:
# netstat -nr
Routing tables
Destination Gateway Flags Refcnt Use Interface
127.0.0.1 127.0.0.1 UH 1 28 lo0
default 172.16.25.3 U 0 0 ppp0
172.16.15.0 172.16.15.1 U 21 1687 le0The contents of routing tables are explained in detail in the next chapter. For now, just notice that the interface used for the default route is ppp0 and that the default route is a route to the remote PPP server (172.16.25.3 in the example).
If the script creates the connection, the interface is installed, and the routing table contains the default route, everything should work fine. If you still have problems they may be related to other parts of the TCP/IP installation. Refer to Chapter 13 for more troubleshooting information.
[61] Check your system documentation to find out exactly how to configure PPP on your system.
[62] If a default route already exists in the routing table, the
defaultroute option is
ignored.
[63] If your modem doesn’t use the full Hayes modem command set,
avoid using dip commands, such
as rest and dial, that generate Hayes commands. Use
send instead. This allows you
to send any string you want to the modem.
[64] If you have call waiting, turn it off before you attempt to make a PPP connection. Different local telephone companies may use different codes to disable call waiting.
[65] For me, the PPP dial-up is just a backup; like many other people I use a high-speed connection. However, DSL and cable modem connections do not require a special configuration because the interface to most DSL and cable modems is Ethernet.
[66] See Appendix A for more details.