faq

经典的ppp程序

This is a list of Frequently Asked Questions about using ppp-2.x and
their answers.


------------------------------------------------------------------------

Q: Can you give me an example of how I might set up my machine to dial
out to an ISP?

A: Here's an example for dialling out to an ISP via a modem on
/dev/tty02.  The modem uses hardware (CTS/RTS) flow control, and the
serial port is run at 38400 baud.  The ISP assigns our IP address.

To configure pppd for this connection, create a file under
/etc/ppp/peers called (say) my-isp containing the following:

tty02 crtscts 38400
connect 'chat -v -f /etc/ppp/chat/my-isp'
defaultroute

The ppp connection is then initiated using the following command:

pppd call my-isp

Of course, if the directory containing pppd is not in your path, you
will need to give the full pathname for pppd, for example,
/usr/sbin/pppd.

When you run this, pppd will use the chat program to dial the ISP and
invoke its ppp service.  Chat will read the file specified with -f,
namely /etc/ppp/chat/my-isp, to find a list of strings to expect to
receive, and strings to send.  This file would contain something like
this:

ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ABORT "Username/Password Incorrect"
"" "at"
OK "at&d2&c1"
OK "atdt2479381"
"name:" "^Uusername"
"word:" "\qpassword"
"annex" "\q^Uppp"
"Switching to PPP-ppp-Switching to PPP"

You will need to change the details here.  The first string on each
line is a string to expect to receive; the second is the string to
send.  You can add or delete lines according to the dialog required to
access your ISP's system.  This example is for a modem with a standard
AT command set, dialling out to an Annex terminal server.  The \q
toggles "quiet" mode; when quiet mode is on, the strings to be sent
are replaced by ?????? in the log.  You may need to go through the
dialog manually using kermit or tip first to determine what should go
in the script.

To terminate the link, run the following script, called (say)
kill-ppp:

#!/bin/sh
unit=ppp${1-0}
piddir=/var/run
if [ -f $piddir/$unit.pid ]; then
  kill -1 `cat $piddir/$unit.pid`
fi

On some systems (SunOS, Solaris, Ultrix), you will need to change
/var/run to /etc/ppp.


------------------------------------------------------------------------

Q: Can you give me an example of how I could set up my office machine
so I can dial in to it from home?

A: Let's assume that the office machine is called "office" and is on a
local ethernet subnet.  Call the home machine "home" and give it an IP
address on the same subnet as "office".  We'll require both machines
to authenticate themselves to each other.

Set up the files on "office" as follows:

/etc/ppp/options contains:

auth		# require the peer to authenticate itself
lock
# other options can go here if desired

/etc/ppp/chap-secrets contains:

home	office	"beware the frub-jub"	home
office	home	"bird, my son!%&*"	-

Set up a modem on a serial port so that users can dial in to the
modem and get a login prompt.

On "home", set up the files as follows:

/etc/ppp/options contains the same as on "office".

/etc/ppp/chap-secrets contains:

home	office	"beware the frub-jub"	-
office	home	"bird, my son!%&*"	office

Create a file called /etc/ppp/peers/office containing the following:

tty02 crtscts 38400
connect 'chat -v -f /etc/ppp/chat/office'
defaultroute

(You may need to change some of the details here.)

Create the /etc/ppp/chat/office file containing the following:

ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ABORT "ogin incorrect"
"" "at"
OK "at&d2&c1"
OK "atdt2479381"
"name:" "^Uusername"
"word:" "\qpassword"
"$" "\q^U/usr/sbin/pppd proxyarp"
"~"

You will need to change the details.  Note that the "$" in the
second-last line is expecting the shell prompt after a successful
login - you may need to change it to "%" or something else.

You then initiate the connection (from home) with the command:

pppd call office

------------------------------------------------------------------------

Q: When I try to establish a connection, the modem successfully dials
the remote system, but then hangs up a few seconds later.  How do I
find out what's going wrong?

A: There are a number of possible problems here.  The first thing to
do is to ensure that pppd's messages are visible.  Pppd uses the
syslog facility to log messages which help to identify specific
problems.  Messages from pppd have facility "daemon" and levels
ranging from "debug" to "error".

Usually it is useful to see messages of level "notice" or higher on
the console.  To see these, find the line in /etc/syslog.conf which
has /dev/console on the right-hand side, and add "daemon.notice" in
the list on the left.  The line will end up looking something like
this:

*.err;kern.debug;auth.notice;mail.crit;daemon.notice	/dev/console

Note that the whitespace is tabs, *not* spaces.

If you are having problems, it may be useful to see messages of level
"info" as well, in which case you would change "daemon.notice" to
"daemon.info".

In addition, it is useful to collect pppd's debugging output in a
file - the debug option to pppd causes it to log the contents of all
control packets sent and received in human-readable form.  To do this,
add a line like this to /etc/syslog.conf:

daemon,local2.debug		/etc/ppp/log

and create an empty /etc/ppp/log file.

When you change syslog.conf, you will need to send a HUP signal to
syslogd to causes it to re-read syslog.conf.  You can do this with a
command like this (as root):

	kill -HUP `cat /etc/syslogd.pid`

(On some systems, you need to use /var/run/syslog.pid instead of
/etc/syslogd.pid.)

After setting up syslog like this, you can use the -v flag to chat and
the `debug' option to pppd to get more information.  Try initiating
the connection again; when it fails, inspect /etc/ppp/log to see what
happened and where the connection failed.


------------------------------------------------------------------------

Q: When I try to establish a connection, I get an error message saying
"Serial link is not 8-bit clean".  Why?

A: The most common cause is that your connection script hasn't
successfully dialled out to the remote system and invoked ppp service
there.  Instead, pppd is talking to something (a shell or login
process on the remote machine, or maybe just the modem) which is only
outputting 7-bit characters.

This can also arise with a modem which uses an AT command set if the
dial command is issued before pppd is invoked, rather than within a
connect script started by pppd.  If the serial port is set to 7
bits/character plus parity when the last AT command is issued, the
modem serial port will be set to the same setting.

Note that pppd *always* sets the local serial port to 8 bits per
character, with no parity and 1 stop bit.  So you shouldn't need to
issue an stty command before invoking pppd.


------------------------------------------------------------------------

Q: When I try to establish a connection, I get an error message saying
"Serial line is looped back".  Why?

A: Probably your connection script hasn't successfully dialled out to
the remote system and invoked ppp service there.  Instead, pppd is
talking to something which is just echoing back the characters it
receives.  The -v option to chat can help you find out what's going
on.  It can be useful to include "~" as the last expect string to
chat, so chat won't return until it's seen the start of the first PPP
frame from the remote system.

Another possibility is that your phone connection has dropped for some
obscure reason and the modem is echoing the characters it receives
from your system.


------------------------------------------------------------------------

Q: I installed pppd successfully, but when I try to run it, I get a
message saying something like "peer authentication required but no
authentication files accessible".

A: When pppd is used on a machine which already has a connection to
the Internet (or to be more precise, one which has a default route in
its routing table), it will require all peers to authenticate
themselves.  The reason for this is that if you don't require
authentication, you have a security hole, because the peer can
basically choose any IP address it wants, even the IP address of some
trusted host (for example, a host mentioned in some .rhosts file).

On machines which don't have a default route, pppd does not require
the peer to authenticate itself.  The reason is that such machines
would mostly be using pppd to dial out to an ISP which will refuse to
authenticate itself.  In that case the peer can use any IP address as
long as the system does not already have a route to that address.
For example, if you have a local ethernet network, the peer can't use
an address on that network.  (In fact it could if it authenticated
itself and it was permitted to use that address by the pap-secrets or
chap-secrets file.)

There are 3 ways around the problem:

1. If possible, arrange for the peer to authenticate itself, and
create the necessary secrets files (/etc/ppp/pap-secrets and/or
/etc/ppp/chap-secrets).

2. If the peer refuses to authenticate itself, and will always be
using the same IP address, or one of a small set of IP addresses, you
can create an entry in the /etc/ppp/pap-secrets file like this:

  ""	  *	  ""	  his-ip.his-domain his-other-ip.other-domain

(that is, using the empty string for the client name and password
fields).  Of couse, you replace the 4th and following fields in the
example above with the IP address(es) that the peer may use.  You can
use either hostnames or numeric IP addresses.

3. You can add the `noauth' option to the /etc/ppp/options file.
Pppd will then not ask the peer to authenticate itself.  If you do
this, I *strongly* recommend that you remove the set-uid bit from the
permissions on the pppd executable, with a command like this:

	chmod u-s /usr/sbin/pppd

Then, an intruder could only use pppd maliciously if they had already
become root, in which case they couldn't do any more damage using pppd
than they could anyway.


------------------------------------------------------------------------

Q: What do I need to put in the secrets files?

A: Three things:
   - secrets (i.e. passwords) to use for authenticating this host to
     other hosts (i.e., for proving our identity to others);
   - secrets which other hosts can use for authenticating themselves
     to us (i.e., so that they can prove their identity to us); and
   - information about which IP addresses other hosts may use, once
     they have authenticated themselves.

There are two authentication files: /etc/ppp/pap-secrets, which
contains secrets for use with PAP (the Password Authentication
Protocol), and /etc/ppp/chap-secrets, which contains secrets for use
with CHAP (the Challenge Handshake Authentication Protocol).  Both
files have the same simple format, which is as follows:

- The file contains a series of entries, each of which contains a
secret for authenticating one machine to another.

- Each entry is contained on a single logical line.  A logical line
may be continued across several lines by placing a backslash (\) at
the end of each line except the last.

- Each entry has 3 or more fields, separated by whitespace (spaces
and/or tabs).  These fields are, in order:
	* The name of the machine that is authenticating itself
	  (the "client").
	* The name of the machine that is authenticating the client
	  (the "server").
	* The secret to be used for authenticating that client to that
	  server.  If this field begins with the at-sign `@', the rest
	  of the field is taken as the name of a file containing the
	  actual secret.
	* The 4th and any following fields list the IP address(es)