path: root/usr.sbin/pppd/RELNOTES

This is the README file for ppp-2.3, 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 establish
a network connection over a serial link.  At present, this package
supports IP and the protocols layered above IP, such as TCP and UDP.
The Linux port of this package also has support for IPX.

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, Solaris 2.x, System V Release 4, 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.


Installation.
*************

The file SETUP contains general information about setting up your
system for using PPP.  There is also a README file for each supported
system, which contains more specific details for installing PPP on
that system.  The supported systems, and the corresponding README
files, are:

	Digital Unix (OSF/1)		README.osf
	Linux				README.linux
	NetBSD, FreeBSD			README.bsd
	NeXTStep			README.next
	Solaris 2			README.sol2
	SunOS 4.x			README.sunos4
	System V Release 4		README.svr4
	Ultrix 4.x			README.ultrix

Unfortunately, AIX 4 is no longer supported, since I don't have a
maintainer for the AIX 4 port.  If you want to volunteer, contact me.
The Ultrix port is untested, as I no longer have access to an Ultrix
box.

In each case you start by running the ./configure script.  This works
out which operating system you are using and creates symbolic links to
the appropriate makefiles.  You then run `make' to compile the
user-level code, and (as root) `make install' to install the
user-level programs pppd, chat and pppstats.

The procedures for installing the kernel code vary from system to
system.  On some systems, the kernel code can be loaded into a running
kernel using a `modload' facility.  On others, the kernel image has to
be recompiled and the system rebooted.  See the README.* files for
details.

N.B. Since 2.3.0, leaving the permitted IP addresses column of the
pap-secrets or chap-secrets file empty means that no addresses are
permitted.  You need to put a "*" in that column to allow the peer to
use any IP address.  (This only applies where the peer is
authenticating itself to you, of course.)


What's new in ppp-2.3.5.
************************

* Minor corrections to the Digital UNIX and NetBSD ports.

* A workaround to avoid tickling a bug in the `se' serial port driver
on Sun PCI Ultra machines running Solaris.

* Fixed a bug in the negotiation of the Microsoft WINS server address
option.

* Fixed a bug in the Linux port where it would fail for kernel
versions above 2.1.99.


What was new in ppp-2.3.4.
**************************

* The NeXT port has been updated, thanks to Steve Perkins.

* ppp-2.3.4 compiles and works under Solaris 2.6, using either gcc or
cc.

* With the Solaris, SVR4 and SunOS ports, you can control the choice
of C compiler, C compiler options, and installation directories by
editing the svr4/Makedefs or sunos4/Makedefs file.

* Until now, we have been using the number 24 to identify Deflate
compression in the CCP negotiations, which was the number in the draft
RFC describing Deflate.  The number actually assigned to Deflate is
26.  The code has been changed to use 26, but to allow the use of 24
for now for backwards compatibility.  (This can be disabled with the
`nodeflatedraft' option to pppd.)

* Fixed some bugs in the linux driver and deflate compressor which
were causing compression problems, including corrupting long
incompressible packets sometimes.

* Fixes to the PAM and shadow password support in pppd, from Al
Longyear and others.

* Pppd now sets some environment variables for scripts it invokes
(ip-up/down, auth-ip/down), giving information about the connection.
The variables it sets are PEERNAME, IPLOCAL, IPREMOTE, UID, DEVICE,
SPEED, and IFNAME.

* Pppd now has an `updetach' option, which will cause it to detach
from its controlling terminal once the link has come up (i.e. once it
is available for IP traffic).


What was new in ppp-2.3.3.
**************************

* Fixed compilation problems under SunOS.

* Fixed a bug introduced into chat in 2.3.2, and compilation problems
introduced into the MS-CHAP implementation in 2.3.2.

* The linux kernel driver has been updated for recent 2.1-series
kernel changes, and it now will ask kerneld to load compression
modules when required, if the kernel is configured to support kerneld.

* Pppd should now compile correctly under linux on systems with glibc.


What was new in ppp-2.3.2.
**************************

* In 2.3.1, I made a change which was intended to make pppd able to
detect loss of CD during or immediately after the connection script
runs.  Unfortunately, this had the side-effect that the connection
script wouldn't work at all on some systems.  This change has been
reversed.

* Fix compilation problems in the Linux kernel driver.


What was new in ppp-2.3.1.
**************************

* Enhancements to chat, thanks to Francis Demierre.  Chat can now
accept comments in the chat script file, and has new SAY, HANGUP,
CLR_ABORT and CLR_REPORT keywords.

* Fixed a bug which causes 2.3.0 to crash Solaris systems.

* Bug-fixes and restructuring of the Linux kernel driver.

* The holdoff behaviour of pppd has been changed slightly: now, if
the link comes up for IP (or other network protocol) traffic, we
consider that the link has been successfully established, and don't
enforce the holdoff period after the link goes down.

* Pppd should now correctly wait for CD (carrier detect) from the
modem, even when the serial port initially had CLOCAL set, and it
should also detect loss of CD during or immediately after the
connection script runs.

* Under linux, pppd will work with older 2.2.0* version kernel
drivers, although demand-dialling is not supported with them.

* Minor bugfixes for pppd.


What was new in ppp-2.3.
************************

* Demand-dialling.  Pppd now has a mode where it will establish the
network interface immediately when it starts, but not actually bring
the link up until it sees some data to be sent.  Look for the demand
option description in the pppd man page.  Demand-dialling is not
supported under Ultrix or NeXTStep.

* Idle timeout.  Pppd will optionally terminate the link if no data
packets are sent or received within a certain time interval.

* Pppd now runs the /etc/ppp/auth-up script, if it exists, when the
peer successfully authenticates itself, and /etc/ppp/auth-down when
the connection is subsequently terminated.  This can be useful for
accounting purposes.

* A new packet compression scheme, Deflate, has been implemented.
This uses the same compression method as `gzip'.  This method is free
of patent or copyright restrictions, and it achieves better
compression than BSD-Compress.  It does consume more CPU cycles for
compression than BSD-Compress, but this shouldn't be a problem for
links running at 100kbit/s or less.

* There is no code in this distribution which is covered by Brad
Clements' restrictive copyright notice.  The STREAMS modules for SunOS
and OSF/1 have been rewritten, based on the Solaris 2 modules, which
were written from scratch without any Clements code.

* Pppstats has been reworked to clean up the output format somewhat.
It also has a new -d option which displays data rate in kbyte/s for
those columns which would normally display bytes.

* Pppd options beginning with - or + have been renamed, e.g. -ip
became noip, +chap became require-chap, etc.  The old options are
still accepted for compatibility but may be removed in future.

* Pppd now has some options (such as the new `noauth' option) which
can only be specified if it is being run by root, or in an
"privileged" options file: /etc/ppp/options or an options file in the
/etc/ppp/peers directory.  There is a new "call" option to read
options from a file in /etc/ppp/peers, making it possible for non-root
users to make unauthenticated connections, but only to certain trusted
peers.  My intention is to make the `auth' option the default in a
future release.

* Several minor new features have been added to pppd, including the
maxconnect and welcome options.  Pppd will now terminate the
connection when there are no network control protocols running.  The
allowed IP address(es) field in the secrets files can now specify
subnets (with a notation like 123.45.67.89/24) and addresses which are
not acceptable (put a ! on the front).

* Numerous bugs have been fixed (no doubt some have been introduced :-)
Thanks to those who reported bugs in ppp-2.2.


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.
*********

The comp.protocols.ppp newsgroup is a useful place to get help if you
have trouble getting your ppp connections to work.  Please do not send
me questions of the form "please help me get connected to my ISP" -
I'm sorry, but I simply do not have the time to answer all the
questions like this that I get.

If you find bugs in this package, please report them to the maintainer
for the port for the operating system you are using:

Digital Unix (OSF/1)	Farrell Woods <ftw@zk3.dec.com>
Linux			Al Longyear <longyear@pobox.com>
NetBSD			Matthew Green <mrg@eterna.com.au
FreeBSD			Peter Wemm <peter@haywire.DIALix.COM>
NeXTStep		Steve Perkins <perkins@cps.msu.edu>
Solaris 2		Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
SunOS 4.x		Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
System V Release 4	Matthias Apitz <Matthias.Apitz@SOFTCON.de>
Ultrix 4.x		Paul Mackerras (for want of anybody better :-)


Copyrights:
***********

All of the code can be freely used and redistributed.


Distribution:
*************

The primary site for releases of this software is:

	ftp://cs.anu.edu.au/pub/software/ppp/

-------------------------
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.