296 lines
12 KiB
Plaintext
296 lines
12 KiB
Plaintext
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.
|