2646609bb7
rather out of date.. it even suggested that it was ppp-2.1.1 still :-) I've selected some bits from the README files and pre-pended it so that at least reading it tells you _something_ about the recent history.
443 lines
18 KiB
Plaintext
443 lines
18 KiB
Plaintext
This is the README file for ppp-2.2, a package which implements the
|
|
Point-to-Point Protocol (PPP) to provide Internet connections over
|
|
serial lines.
|
|
|
|
|
|
Introduction.
|
|
*************
|
|
|
|
The Point-to-Point Protocol (PPP) provides a standard way to transmit
|
|
datagrams over a serial link, as well as a standard way for the
|
|
machines at either end of the link (the `peers') to negotiate various
|
|
optional characteristics of the link. Using PPP, a serial link can be
|
|
used to transmit Internet Protocol (IP) datagrams, allowing TCP/IP
|
|
connections between the peers. PPP is defined in several RFC (Request
|
|
For Comments) documents, in particular RFCs 1661, 1662, 1332 and 1334.
|
|
Other RFCs describe standard ways to transmit datagrams from other
|
|
network protocols (e.g., DECnet, OSI, Appletalk), but this package
|
|
only supports IP.
|
|
|
|
This software consists of two parts:
|
|
|
|
- Kernel code, which establishes a network interface and passes
|
|
packets between the serial port, the kernel networking code and the
|
|
PPP daemon (pppd). This code is implemented using STREAMS modules on
|
|
SunOS 4.x, AIX 4.1 and OSF/1, and as a line discipline under Ultrix,
|
|
NextStep, NetBSD, FreeBSD, and Linux.
|
|
|
|
- The PPP daemon (pppd), which negotiates with the peer to establish
|
|
the link and sets up the ppp network interface. Pppd includes support
|
|
for authentication, so you can control which other systems may make a
|
|
PPP connection and what IP addresses they may use.
|
|
|
|
|
|
What is new in ppp-2.2.
|
|
***********************
|
|
|
|
* More systems are now supported:
|
|
|
|
AIX 4, thanks to Charlie Wick,
|
|
OSF/1 on DEC Alpha, thanks to Steve Tate (srt@zaphod.csci.unt.edu),
|
|
NextStep 3.2 and 3.3, thanks to Philip-Andrew Prindeville
|
|
(philipp@res.enst.fr) and Steve Perkins (perkins@cps.msu.edu),
|
|
Solaris 2,
|
|
|
|
in addition to NetBSD 1.0, SunOS 4.x, Ultrix 4.x, FreeBSD 2.0, and
|
|
Linux.
|
|
|
|
* Packet compression has been implemented. This version implements
|
|
CCP (Compression Control Protocol) and the BSD-Compress compression
|
|
scheme according to the current draft RFCs. This means that incoming
|
|
and outgoing packets can be compressed with the LZW scheme (same as
|
|
the `compress' command) using a code size of up to 15 bits.
|
|
|
|
* Some bug fixes to the LCP protocol code. In particular, pppd now
|
|
correctly replies with a Configure-NAK (instead of a Configure-Reject)
|
|
if the peer asks for CHAP and pppd is willing to do PAP but not CHAP.
|
|
|
|
* The ip-up and ip-down scripts are now run with the real user ID set
|
|
to root, and with an empty environment. Clearing the environment
|
|
fixes a security hole.
|
|
|
|
* The kernel code on NetBSD, FreeBSD, NextStep and Ultrix has been
|
|
restructured to make it easier to implement PPP over devices other
|
|
than asynchronous tty ports (for example, synchronous serial ports).
|
|
|
|
* pppd now looks at the list of interfaces in the system to determine
|
|
what the netmask should be. In most cases, this should eliminate the
|
|
need to use the `netmask' option.
|
|
|
|
* There is a new `papcrypt' option to pppd, which specifies that
|
|
secrets in /etc/ppp/pap-secrets used for authenticating the peer are
|
|
encrypted, so pppd always encrypts the peer's password before
|
|
comparing it with the secret from /etc/ppp/pap-secrets. This gives
|
|
better security.
|
|
|
|
|
|
Patents.
|
|
********
|
|
|
|
The BSD-Compress algorithm used for packet compression is the same as
|
|
that used in the Unix "compress" command. It is apparently covered by
|
|
U.S. patents 4,814,746 (owned by IBM) and 4,558,302 (owned by Unisys),
|
|
and corresponding patents in various other countries (but not
|
|
Australia). If this is of concern, you can build the package without
|
|
including BSD-Compress. To do this, edit net/ppp-comp.h to change the
|
|
definition of DO_BSD_COMPRESS to 0. The bsd-comp.c files are then no
|
|
longer needed, so the references to bsd-comp.o may optionally be
|
|
removed from the Makefiles.
|
|
|
|
|
|
Contacts.
|
|
*********
|
|
|
|
Bugs in the the SunOS, NetBSD and Ultrix ports and bugs in pppd, chat
|
|
or pppstats should be reported to:
|
|
|
|
paulus@cs.anu.edu.au
|
|
Paul Mackerras
|
|
Dept. of Computer Science
|
|
Australian National University
|
|
Canberra ACT 0200
|
|
AUSTRALIA
|
|
|
|
Bugs in other ports should be reported to the maintainer for that port
|
|
(see the appropriate README.* file) or to the above. Unfortunately,
|
|
Charlie Wick is not in a position to provide support for the AIX 4
|
|
port, so if you find bugs in it, send them to me.
|
|
|
|
Thanks to:
|
|
|
|
Brad Parker (brad@fcr.com)
|
|
Greg Christy (gmc@quotron.com)
|
|
Drew D. Perkins (ddp@andrew.cmu.edu)
|
|
Rick Adams (rick@seismo.ARPA)
|
|
Chris Torek (chris@mimsy.umd.edu, umcp-cs!chris).
|
|
|
|
|
|
Copyrights:
|
|
|
|
Most of the code can be freely used and redistributed. The STREAMS
|
|
code for SunOS 4.x, OSF/1 and AIX 4 is under a more restrictive
|
|
copyright:
|
|
|
|
This code is Copyright (C) 1989, 1990 By Brad K. Clements,
|
|
All Rights Reserved.
|
|
|
|
You may use this code for your personal use, to provide a non-profit
|
|
service to others, or to use as a test platform for a commercial
|
|
implementation.
|
|
|
|
You may NOT use this code in a commercial product, nor to provide a
|
|
commercial service, nor may you sell this code without express
|
|
written permission of the author.
|
|
|
|
Otherwise, Enjoy!
|
|
|
|
This copyright applies to (parts of) the following files:
|
|
|
|
sunos/ppp_async.c
|
|
sunos/ppp_if.c
|
|
aix4/ppp_async.c
|
|
aix4/ppp_if.c
|
|
net/ppp_str.h
|
|
pppd/sys-str.c
|
|
pppd/sys-osf.c
|
|
pppd/sys-aix4.c
|
|
-------------------------
|
|
pppd-2.1.1 release notes
|
|
Paul Mackerras 27 May 1994
|
|
|
|
This file details the new and changed features in pppd since version 1.3.
|
|
Briefly:
|
|
- the protocol code has been updated to conform with
|
|
RFCs 1548, 1549, 1332 and 1334
|
|
- security has been improved
|
|
- functionality has been improved in various ways.
|
|
|
|
|
|
NEW FEATURES
|
|
|
|
* The option negotiation automaton has been updated to RFC1548. LCP
|
|
now rejects the Quality Protocol option, since LQR is not implemented
|
|
yet. IPCP now uses the IP-Address option, and falls back to the old
|
|
IP-Addresses option if the IP-Address option is rejected. IPCP also
|
|
uses the new form of the VJ-Compression option.
|
|
|
|
RFC1548 defines the "passive" option to mean that the automaton
|
|
outputs configure-request packets initially, but does not close down
|
|
if no answer is received. A valid configure-request received will
|
|
restart the negotiation. The "silent" option has been added with the
|
|
old meaning of "passive", i.e. the automaton will not output
|
|
configure-requests until it receives a valid one from the peer.
|
|
|
|
* More systems are supported: in addition to SunOS 4.x and BSD/Net-2
|
|
derived systems, Ultrix and Linux are supported, thanks to Robert
|
|
Olsson, Per Sundstrom, Michael Callahan and Al Longyear.
|
|
|
|
* Options can be taken from files as well as the command line. pppd
|
|
reads options from the files /etc/ppp/options and ~/.ppprc before
|
|
looking at the command line, and /etc/ppp/options.<ttyname> after
|
|
interpreting the options on the command line. An options file is
|
|
parsed into a series of words, delimited by whitespace. Whitespace
|
|
can be included in a word by enclosing the word in quotes (").
|
|
Backslash (\) quotes the following character. A hash (#) starts a
|
|
comment, which continues until the end of the line. In addition, the
|
|
`file' option causes pppd to read options from a file. pppd will
|
|
report and error and exit if ~/.ppprc or the file given as the
|
|
argument to the `file' option cannot be read by the user who invoked
|
|
pppd.
|
|
|
|
* On those systems, such as NetBSD, where the serial line speed is
|
|
stored in the termios structure in bits per second (i.e. B9600 ==
|
|
9600), it is possible to set any speed.
|
|
|
|
* If desired, pppd will output LCP echo-request frames periodically
|
|
while the link is up, and take the link down if no replies are
|
|
received to a user-configurable number of echo-requests. This can be
|
|
used to detect that the serial connection has been broken on those
|
|
systems which don't have hardware modem control lines.
|
|
|
|
AUTHENTICATION
|
|
|
|
Previous versions of pppd have provided no control over which IP
|
|
addresses the peer can use. Thus it is possible for the peer to
|
|
impersonate another host on the local network, leading to various
|
|
security holes. In addition, the authentication mechanisms were quite
|
|
weak: if the peer refused to agree to authenticate, pppd would print a
|
|
warning message but still allow the link to come up. The CHAP
|
|
implementation also appeared to be quite broken (has anybody actually
|
|
used it?).
|
|
|
|
This new version of pppd addresses these problems. My aim has been to
|
|
provide system administrators with sufficient access control that PPP
|
|
access to a server machine can be provided to legitimate users without
|
|
fear of compromising the security of the server or the network it's
|
|
on. In part this is provided by the /etc/ppp/options file, where the
|
|
administrator can place options to require authentication which cannot
|
|
be disabled by users. Thus the new pppd can made setuid-root and run
|
|
by users.
|
|
|
|
The behaviour where pppd refuses to run unless the /etc/ppp/options
|
|
file is present and readable by pppd is now the default behaviour. If
|
|
you really want pppd to run without the presence of the
|
|
/etc/ppp/options file, you will have to include -DREQ_SYSOPTIONS=0 on
|
|
the compilation command line.
|
|
|
|
The options related to authentication are:
|
|
|
|
auth Require authentication from the peer. If neither
|
|
+chap or +pap is also given, either CHAP or PAP
|
|
authentication will be accepted.
|
|
+chap Require CHAP authentication from the peer.
|
|
+pap Require PAP authentication from the peer.
|
|
-chap Don't agree to authenticate ourselves with the peer
|
|
using CHAP.
|
|
-pap Don't agree to authenticate ourselves using PAP.
|
|
+ua <f> Get username and password for authenticating ourselves
|
|
with the peer using PAP from file <f>.
|
|
name <n> Use <n> as the local name for authentication.
|
|
usehostname Use this machine's hostname as the local name for
|
|
authentication.
|
|
remotename <n> Use <n> as the name of the peer for authentication.
|
|
login If the peer authenticates using PAP, check the
|
|
supplied username and password against the system
|
|
password database, and make a wtmp entry.
|
|
user <n> Use <n> as the username for authenticating ourselves
|
|
using PAP.
|
|
|
|
The defaults are to agree to authenticate if requested, and to not
|
|
require authentication from the peer. However, pppd will not agree to
|
|
authenticate itself with a particular protocol if it has no secrets
|
|
which could be used to do so.
|
|
|
|
Authentication is based on secrets, which are selected from secrets
|
|
files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP).
|
|
Both secrets files have the same format, and both can store secrets
|
|
for several combinations of server (authenticating peer) and client
|
|
(peer being authenticated). Note that each end can be both a server
|
|
and client, and that different protocols can be used in the two
|
|
directions if desired.
|
|
|
|
A secrets file is parsed into words as for a options file. A secret
|
|
is specified by a line containing at least 3 words, in the order
|
|
client, server, secret. Any following words on the same line are
|
|
taken to be a list of acceptable IP addresses for that client. If
|
|
there are only 3 words on the line, it is assumed that any IP address
|
|
is OK; to disallow all IP addresses, use "-". If the secret starts
|
|
with an `@', what follows is assumed to be the name of a file from
|
|
which to read the secret. A "*" as the client or server name matches
|
|
any name. When selecting a secret, pppd takes the best match, i.e.
|
|
the match with the fewest wildcards.
|
|
|
|
Thus a secrets file contains both secrets for use in authenticating
|
|
other hosts, plus secrets which we use for authenticating ourselves to
|
|
others. Which secret to use is chosen based on the names of the host
|
|
(the `local name') and its peer (the `remote name'). The local name
|
|
is set as follows:
|
|
|
|
if the `usehostname' option is given,
|
|
then the local name is the hostname of this machine
|
|
(with the domain appended, if given)
|
|
|
|
else if the `name' option is given,
|
|
then use the argument of the first `name' option seen
|
|
|
|
else if the local IP address is specified with a
|
|
host name (e.g. `sirius:')
|
|
then use that host name
|
|
|
|
else use the hostname of this machine
|
|
(with the domain appended, if given)
|
|
|
|
When authenticating ourselves using PAP, there is also a `username'
|
|
which is the local name by default, but can be set with the `user'
|
|
option or the `+ua' option.
|
|
|
|
The remote name is set as follows:
|
|
|
|
if the `remotename' option is given,
|
|
then use the argument of the last `remotename' option seen
|
|
|
|
else if the remote IP address is specified with a
|
|
host name (e.g. `avago:')
|
|
then use that host name
|
|
|
|
else the remote name is the null string "".
|
|
|
|
Secrets are selected from the PAP secrets file as follows:
|
|
|
|
- For authenticating the peer, look for a secret with client ==
|
|
username specified in the PAP authenticate-request, and server ==
|
|
local name.
|
|
|
|
- For authenticating ourselves to the peer, look for a secret with
|
|
client == our username, server == remote name.
|
|
|
|
When authenticating the peer with PAP, a secret of "" matches any
|
|
password supplied by the peer. If the password doesn't match the
|
|
secret, the password is encrypted using crypt() and checked against
|
|
the secret again; thus secrets for authenticating the peer can be
|
|
stored in encrypted form. If the `login' option was specified, the
|
|
username and password are also checked against the system password
|
|
database. Thus, the system administrator can set up the pap-secrets
|
|
file to allow PPP access only to certain users, and to restrict the
|
|
set of IP addresses that each user can use.
|
|
|
|
Secrets are selected from the CHAP secrets file as follows:
|
|
|
|
- For authenticating the peer, look for a secret with client == name
|
|
specified in the CHAP-Response message, and server == local name.
|
|
|
|
- For authenticating ourselves to the peer, look for a secret with
|
|
client == local name, and server == name specified in the
|
|
CHAP-Challenge message.
|
|
|
|
Authentication must be satisfactorily completed before IPCP (or any
|
|
other Network Control Protocol) can be started. If authentication
|
|
fails, pppd will terminated the link (by closing LCP). If IPCP
|
|
negotiates an unacceptable IP address for the remote host, IPCP will
|
|
be closed. IP packets cannot be sent or received until IPCP is
|
|
successfully opened.
|
|
|
|
(some examples needed here perhaps)
|
|
|
|
|
|
ROUTING
|
|
|
|
Setting the addresses on a ppp interface is sufficient to create a
|
|
host route to the remote end of the link. Sometimes it is desirable
|
|
to add a default route through the remote host, as in the case of a
|
|
machine whose only connection to the Internet is through the ppp
|
|
interface. The `defaultroute' option causes pppd to create such a
|
|
default route when IPCP comes up, and delete it when the link is
|
|
terminated.
|
|
|
|
In some cases it is desirable to use proxy ARP, for example on a
|
|
server machine connected to a LAN, in order to allow other hosts to
|
|
communicate with the remote host. The `proxyarp' option causes pppd
|
|
to look for a network interface (an interface supporting broadcast and
|
|
ARP, which is up and not a point-to-point or loopback interface) on
|
|
the same subnet as the remote host. If found, pppd creates a
|
|
permanent, published ARP entry with the IP address of the remote host
|
|
and the hardware address of the network interface found.
|
|
|
|
|
|
OTHER NEW AND CHANGED OPTIONS
|
|
|
|
modem Use modem control lines (not fully implemented
|
|
yet)
|
|
local Don't use modem control lines
|
|
persist Keep reopening connection (not fully
|
|
implemented yet)
|
|
|
|
lcp-restart <n> Set timeout for LCP retransmissions to <n>
|
|
seconds (default 3 seconds)
|
|
lcp-max-terminate <n> Set maximum number of LCP terminate-request
|
|
transmissions (default 2)
|
|
lcp-max-configure <n> Set maximum number of LCP configure-request
|
|
transmissions (default 10)
|
|
lcp-max-failure <n> Set maximum number of LCP configure-Naks sent
|
|
before converting to configure-rejects
|
|
(default 10)
|
|
|
|
ipcp-restart <n> Set timeout for IPCP retransmissions to <n>
|
|
seconds (default 3 seconds)
|
|
ipcp-max-terminate <n> Set maximum number of IPCP
|
|
terminate-request transmissions (default 2)
|
|
ipcp-max-configure <n> Set maximum number of IPCP
|
|
configure-request transmissions (default 10)
|
|
ipcp-max-failure <n> Set maximum number of IPCP configure-Naks
|
|
sent before converting to configure-rejects
|
|
(default 10)
|
|
|
|
upap-restart <n> Set timeout for PAP retransmissions to
|
|
<n> seconds (default 3 seconds)
|
|
upap-max-authreq <n> Set maximum number of Authenticate-request
|
|
retransmissions (default 10)
|
|
|
|
chap-restart <n> Set timeout for CHAP retransmissions to
|
|
<n> seconds (default 3 seconds)
|
|
chap-max-challenge <n> Set maximum number of CHAP Challenge
|
|
retransmissions (default 10)
|
|
chap-interval <n> Set the interval between CHAP rechallenges
|
|
(default 0, meaning infinity)
|
|
|
|
The -ua option no longer exists.
|
|
|
|
|
|
SOFTWARE RESTRUCTURING
|
|
|
|
Many of the source files for pppd have changed significantly from
|
|
ppp-1.3, upon which it is based. In particular:
|
|
|
|
- the macros for system-dependent operations in pppd.h have mostly
|
|
been removed. Instead these operations are performed by procedures in
|
|
sys-bsd.c (for BSD-4.4ish systems like NetBSD, 386BSD, etc.) or
|
|
sys-str.c (for SunOS-based systems using STREAMS). (I got sick of
|
|
having to recompile everything every time I wanted to change one of
|
|
those horrible macros.)
|
|
|
|
- most of the system-dependent code in main.c has also been removed to
|
|
sys-bsd.c and sys-str.c.
|
|
|
|
- the option processing code in main.c has been removed to options.c.
|
|
|
|
- the authentication code in main.c has been removed to auth.c, which
|
|
also contains substantial amounts of new code.
|
|
|
|
- fsm.c has changed significantly, and lcp.c, ipcp.c, and upap.c have
|
|
changed somewhat. chap.c has also changed significantly.
|
|
|
|
|
|
STILL TO DO
|
|
|
|
* sort out appropriate modem control and implement the persist option
|
|
properly; add an `answer' option for auto-answering a modem.
|
|
|
|
* add an inactivity timeout and demand dialing.
|
|
|
|
* implement link quality monitoring.
|
|
|
|
* implement other network control protocols.
|