faq

经典的ppp程序

	  that the client may use.

- The file may contain comments, which begin with a `#' and continue
to the end of the line.

- Double quotes `"' should be used around a field if it contains
characters with special significance, such as space, tab, `#', etc.

- The backslash `\' may be used before characters with special
significance (space, tab, `#', `\', etc.) to remove that significance.

Some important points to note:

* A machine can be *both* a "client" and a "server" for the purposes
of authentication - this happens when both peers require the other to
authenticate itself.  So A would authenticate itself to B, and B would
also authenticate itself to A (possibly using a different
authentication protocol).

* If both the "client" and the "server" are running ppp-2.x, they need
to have a similar entry in the appropriate secrets file; the first two
fields are *not* swapped on the client, compared to the server.  So
the client might have an entry like this:

	ay	bee	"our little secret"	-

and the corresponding entry on the server could look like this:

	ay	bee	"our little secret"	123.45.67.89


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

Q: Explain about PAP and CHAP?

PAP stands for the Password Authentication Protocol.  With this
protocol, the "client" (the machine that needs to authenticate itself)
sends its name and a password, in clear text, to the "server".  The
server returns a message indicating whether the name and password are
valid.

CHAP stands for the Challenge Handshake Authentication Protocol.  It
is designed to address some of the deficiencies and vulnerabilities of
PAP.  Like PAP, it is based on the client and server having a shared
secret, but the secret is never passed in clear text over the link.
Instead, the server sends a "challenge" - an arbitrary string of
bytes, and the client must prove it knows the shared secret by
generating a hash value from the challenge combined with the shared
secret, and sending the hash value back to the server.  The server
also generates the hash value and compares it with the value received
from the client.

At a practical level, CHAP can be slightly easier to configure than
PAP because the server sends its name with the challenge.  Thus, when
finding the appropriate secret in the secrets file, the client knows
the server's name.  In contrast, with PAP, the client has to find its
password (i.e. the shared secret) before it has received anything from
the server.  Thus, it may be necessary to use the `remotename' option
to pppd when using PAP authentication so that it can select the
appropriate secret from /etc/ppp/pap-secrets.

Microsoft also has a variant of CHAP which uses a different hashing
arrangement from normal CHAP.  There is a client-side implementation
of Microsoft's CHAP in ppp-2.3; see README.MSCHAP80.


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

Q: When the modem hangs up, without the remote system having
terminated the connection properly, pppd does not notice the hangup,
but just keeps running.  How do I get pppd to notice the hangup and
exit?

A: Pppd detects modem hangup by looking for an end-of-file indication
from the serial driver, which should be generated when the CD (carrier
detect) signal on the serial port is deasserted.  For this to work:

- The modem has to be set to assert CD when the connection is made and
deassert it when the phone line hangs up.  Usually the AT&C1 modem
command sets this mode.

- The cable from the modem to the serial port must connect the CD
signal (on pin 8).

- Some serial drivers have a "software carrier detect" mode, which
must be *disabled*.  The method of doing this varies between systems.
Under SunOS, use the ttysoftcar command.  Under NetBSD, edit /etc/ttys
to remove the "softcar" flag from the line for the serial port, and
run ttyflags.


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

Q: Why should I use PPP compression (BSD-Compress or Deflate) when my
modem already does V.42 compression?  Won't it slow the CPU down a
lot?

A: Using PPP compression is preferable, especially when using modems
over phone lines, for the following reasons:

- The V.42 compression in the modem isn't very strong - it's an LZW
technique (same as BSD-Compress) with a 10, 11 or 12 bit code size.
With BSD-Compress you can use a code size of up to 15 bits and get
much better compression, or you can use Deflate and get even better
compression ratios.

- I have found that enabling V.42 compression in my 14.4k modem
increases the round-trip time for a character to be sent, echoed and
returned by around 40ms, from 160ms to 200ms (with error correction
enabled).  This is enough to make it feel less responsive on rlogin or
telnet sessions.  Using PPP compression adds less than 5ms (small
enough that I couldn't measure it reliably).  I admit my modem is a
cheapie and other modems may well perform better.

- While compression and decompression do require some CPU time, they
reduce the amount of time spent in the serial driver to transmit a
given amount of data.  Many machines require an interrupt for each
character sent or received, and the interrupt handler can take a
significant amount of CPU time.  So the increase in CPU load isn't as
great as you might think.  My measurements indicate that a system with
a 33MHz 486 CPU should be able to do Deflate compression for serial
link speeds of up to 100kb/s or more.  It depends somewhat on the type
of data, of course; for example, when compressing a string of nulls
with Deflate, it's hard to get a high output data rate from the
compressor, simply because it compresses strings of nulls so well that
it has to eat a very large amount of input data to get each byte of
output.


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

Q: I get messages saying "Unsupported protocol (...) received".  What do
these mean?

A: If you only get one or two when pppd starts negotiating with the
peer, they mean that the peer wanted to negotiate some PPP protocol
that pppd doesn't understand.  This doesn't represent a problem, it
simply means that there is some functionality that the peer supports
that pppd doesn't, so that functionality can't be used.

If you get them sporadically while the link is operating, or if the
protocol numbers (in parentheses) don't correspond to any valid PPP
protocol that the peer might be using, then the problem is probably
that characters are getting corrupted on the receive side, or that
extra characters are being inserted into the receive stream somehow.
If this is happening, most packets that get corrupted should get
discarded by the FCS (Frame Check Sequence, a 16-bit CRC) check, but a
small number may get through.

One possibility may be that you are receiving broadcast messages on
the remote system which are being sent over your serial link.  Another
possibility is that your modem is set for XON/XOFF (software) flow
control and is inserting ^Q and ^S characters into the receive data
stream.


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

Q: I get messages saying "Protocol-Reject for unsupported protocol ...".
What do these mean?

A: This is the other side of the previous question.  If characters are
getting corrupted on the way to the peer, or if your system is
inserting extra bogus characters into the transmit data stream, the
peer may send protocol-reject messages to you, resulting in the above
message (since your pppd doesn't recognize the protocol number
either.)


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

Q: I get a message saying something like "ioctl(TIOCSETD): Operation
not permitted".  How do I fix this?

A: This is because pppd is not running as root.  If you have not
installed pppd setuid-root, you will have to be root to run it.  If
you have installed pppd setuid-root and you still get this message, it
is probably because your shell is using some other copy of pppd than
the installed one - for example, if you are in the pppd directory
where you've just built pppd and your $PATH has . before /usr/sbin (or
wherever pppd gets installed).


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

Q: Has your package been ported to HP/UX or IRIX or AIX?

A: No.  I don't have access to systems running HP/UX or AIX.  No-one
has volunteered to port it to HP/UX.  I had someone who did a port for
AIX 4.x, but who is no longer able to maintain it.  And apparently AIX
3.x is quite different, so it would need a separate port.

IRIX includes a good PPP implementation in the standard distribution,
as far as I know.


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

Q: Under SunOS 4, when I try to modload the ppp modules, I get the
message "can't open /dev/vd: No such device".

A: First check in /dev that there is an entry like this:

crw-r--r--  1  root         57,   0 Oct 2  1991 vd

If not, make one (mknod /dev/vd c 57 0).  If the problem still exists,
probably your kernel has been configured without the vd driver
included.  The vd driver is needed for loadable module support.

First, identify the config file that was used.  When you boot your
machine, or if you run /etc/dmesg, you'll see a line that looks
something like this:

SunOS Release 4.1.3_U1 (CAP_XBOX) #7: Thu Mar 21 15:31:56 EST 1996
			^^^^^^^^
			this is the config file name

The config file will be in the /sys/`arch -k`/conf directory (arch -k
should return sun4m for a SparcStation 10, sun3x for a Sun 3/80,
etc.).  Look in there for a line saying "options VDDRV".  If that line
isn't present (or is commented out), add it (or uncomment it).

You then need to rebuild the kernel as described in the SunOS
manuals.  Basically you need to run config and make like this:

	/usr/etc/config CAP_XBOX
	cd ../CAP_XBOX
	make

(replacing the string CAP_XBOX by the name of the config file for your
kernel, of course).

Then copy the new kernel to /:

	mv /vmunix /vmunix.working
	cp vmunix /

and reboot.  Modload should then work.


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

Q: I'm running Linux (or NetBSD or FreeBSD), and my system comes with
PPP already.  Should I consider installing this package?  Why?

A: The PPP that is already installed in your system is (or is derived
from) some version of this PPP package.  You can find out what version
of this package is already installed with the command "pppd --help".
If this is older than the latest version, you may wish to install the
latest version so that you can take advantage of the new features or
bug fixes.


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

Q: I'm running pppd in demand mode, and I find that pppd often dials
out unnecessarily when I try to make a connection within my local
machine or with a machine on my local LAN.  What can I do about this?

A: Very often the cause of this is that a program is trying to contact
a nameserver to resolve a hostname, and the nameserver (specified in
/etc/resolv.conf, usually) is on the far side of the ppp link.  You
can try executing a command such as `ping myhost' (where myhost is the
name of the local machine, or some other machine on a local LAN), to
see whether that starts the ppp link.  If it does, check the setup of
your /etc/hosts file to make sure you have the local machine and any
hosts on your local LAN listed, and /etc/resolv.conf and/or
/etc/nsswitch.conf files to make sure you resolve hostnames from
/etc/hosts if possible before trying to contact a nameserver.


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

Q: Since I installed ppp-2.3.6, dialin users to my server have been
getting this message when they run pppd:

peer authentication required but no suitable secret(s) found for 
authenticating any peer to us (ispserver)

A: In 2.3.6, the default is to let an unauthenticated peer only use IP
addresses to which the machine doesn't already have a route.  So on a
machine with a default route, everyone has to authenticate.  If you
really don't want that, you can put `noauth' in the /etc/ppp/options
file.  Note that there is then no check on who is using which IP
address.  IMHO, this is undesirably insecure, but I guess it may be
tolerable as long as you don't use any .rhosts files or anything like
that.  I recommend that you require dialin users to authenticate, even
if just with PAP using their login password (using the `login' option
to pppd).  If you do use `noauth', you should at least have a pppusers
group and set the permissions on pppd to allow only user and group to
execute it.

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

Q: When running pppd as a dial-in server, I often get the message
"LCP: timeout sending Config-Requests" from pppd.  It seems to be
random, but dial-out always works fine.  What is wrong?

A: Most modern modems auto-detects the speed of the serial line
between the modem and the computer.  This auto-detection occurs when
the computer sends characters to the modem, when the modem is in
command mode.  It does not occur when the modem is in data mode.
Thus, if you send commands to the modem at 2400 bps, and then change
the serial port speed to 115200 bps, the modem will not detect this
change until something is transmitted from the computer to the modem.
When running pppd in dial-in mode (i.e. without a connect script),
pppd sets the speed of the serial port, but does not transmit
anything.  If the modem was already running at the specified speed,
everything is fine, but if not, you will just receive garbage from the
modem.  To cure this, use an init script such as the following:

	pppd ttyS0 115200 modem crtscts init "chat '' AT OK"

To reset the modem and enable auto-answer, use:

	pppd ttyS0 115200 modem crtscts init "chat '' ATZ OK ATS0=1 OK"