mirror/ppp
1
0
Fork 0
mirror of https://github.com/ppp-project/ppp.git synced 2025-12-20 01:00:30 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update READMEs etc. for the forthcoming ppp-2.4.5 release

Browse Source 
Signed-off-by: Paul Mackerras <paulus@samba.org>
This commit is contained in:
Paul Mackerras
2008-09-06 18:42:27 +10:00
parent 169be1f832
commit 636e804e95
7 changed files with 51 additions and 688 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
README
View File

@@ -8,11 +8,10 @@ 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 and Solaris ports of this package have optional support for
IPV6; the Linux port of this package also has support for IPX.
supports IP and IPV6 and the protocols layered above them, such as TCP
and UDP. The Linux port of this package also has support for IPX.
This software consists of two parts:
This PPP implementation consists of two parts:
- Kernel code, which establishes a network interface and passes
packets between the serial port, the kernel networking code and the
@@ -29,6 +28,13 @@ code for NeXTStep, FreeBSD, SunOS 4.x, SVR4, Tru64 (Digital Unix), AIX
and Ultrix but no active maintainers for these platforms. Code for
all of these except AIX is included in the ppp-2.3.11 release.
The kernel code for Linux is no longer distributed with this package,
since the relevant kernel code is in the official Linux kernel source
(and has been for many years) and is included in all reasonably modern
Linux distributions. The Linux kernel code supports using PPP over
things other than serial ports, such as PPP over Ethernet and PPP over
ATM.
Installation.
*************
@@ -55,9 +61,25 @@ use any IP address. (This only applies where the peer is
authenticating itself to you, of course.)
What's new in ppp-2.4.4.
What's new in ppp-2.4.5.
************************
* Under Linux, pppd can now operate in a mode where it doesn't request
the peer's IP address, as some peers refuse to supply an IP address.
Since Linux supports device routes as well as gateway routes, it's
possible to have no remote IP address assigned to the ppp interface
and still route traffic over it.
* The PPP over L2TP plugin is included, which works with the pppol2tp
PPP channel code in the Linux kernel. This allows pppd to be used
to set up tunnels using the Layer 2 Tunneling Protocol.
* Several bugs have been fixed.
What was new in ppp-2.4.4.
**************************
* Pppd will now run /etc/ppp/ip-pre-up, if it exists, after creating
the ppp interface and configuring its IP addresses but before
bringing it up. This can be used, for example, for adding firewall
@@ -226,23 +248,6 @@ BSD-Compress and Deflate (which uses the same algorithm as gzip) don't
ever expand packets.
Patents.
********
The BSD-Compress algorithm used for packet compression is the same as
that used in the Unix "compress" command. It was 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). Apparently the Unisys patent expired in the US on 20 June
2003, but the IBM patent is still pending.
If these patents are of concern in your situation, 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.
*********
@@ -276,4 +281,3 @@ The primary site for releases of this software is:
ftp://ftp.samba.org/pub/ppp/
($Id: README,v 1.37 2006/05/29 23:51:29 paulus Exp $)

17
README.MPPE
View File

@@ -4,6 +4,8 @@ PPP Support for MPPE (Microsoft Point to Point Encryption)
Frank Cusack frank@google.com
Mar 19, 2002
Updated by Paul Mackerras, Sep 2008
DISCUSSION
@@ -59,17 +61,9 @@ RADIUS support for MPPE is from Ralf Hofmann, <ralf.hofmann@elvido.net>.
BUILDING THE PPPD
The userland component of PPPD has no additional requirements above
those for MS-CHAP and MS-CHAPv2. The kernel, however, requires SHA-1
and ARCFOUR. Public domain implementations of these are provided.
those for MS-CHAP and MS-CHAPv2.
Until such time as MPPE support ships with kernels, you can use
the Linux 2.2 or 2.4 implementation that comes with PPPD. Run the
ppp/linux/mppe/mppeinstall.sh script, giving it the location to your
kernel source. Then add the CONFIG_PPP_MPPE option to your config and
rebuild the kernel. The ppp_mppe.o module is added, and the ppp.o module
(2.2) or ppp_generic.o (2.4) is modified (unfortunately). You'll need
the new ppp.o/ppp_generic.o since it does the right thing for the 4
extra bytes problem discussed above.
MPPE support is now included in the mainline Linux kernel releases.
CONFIGURATION
@@ -79,7 +73,6 @@ than 2.4.15, you will need to add
alias ppp-compress-18 ppp_mppe
to /etc/modules.conf. (A patch for earlier versions of modutils is included
with the kernel patches.)
to /etc/modules.conf.

62
README.MSCHAP80
View File

@@ -25,65 +25,11 @@ a value of 5. If you enable PPP debugging with the "debug" option and
see something like the following in your logs, the remote server is
requesting MS-CHAP:
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap 80> <magic 0x46a3>]
^^^^^^^^^^^^
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth MS> <magic 0x46a3>]
^^^^^^^
The standard pppd implementation will indicate its lack of support for
MS-CHAP by NAKing it:
sent [LCP ConfNak id=0x2 <auth chap 05>]
Windows NT Server systems are often configured to "Accept only
Microsoft Authentication" (this is intended to enhance security). Up
until now, that meant that you couldn't use this version of PPPD to
connect to such a system.
BUILDING THE PPPD
MS-CHAP uses a combination of MD4 hashing and DES encryption for
authentication. You may need to get Eric Young's libdes library in
order to use my MS-CHAP extensions. A lot of UNIX systems already
have DES encryption available via the crypt(3), encrypt(3) and
setkey(3) interfaces. Some may (such as that on Digital UNIX)
provide only the encryption mechanism and will not perform
decryption. This is okay. We only need to encrypt to perform
MS-CHAP authentication.
If you have encrypt/setkey available, then hopefully you need only
define these two things in your Makefile: -DUSE_CRYPT and -DCHAPMS.
Skip the paragraphs below about obtaining and building libdes. Do
the "make clean" and "make" as described below. Linux users
should not need to modify their Makefiles. Instead,
just do "make CHAPMS=1 USE_CRYPT=1".
If you don't have encrypt and setkey, you will need Eric Young's
libdes library. You can find it in:
ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.psy.uq.oz.au/DES/libdes-3.06.tar.gz
Australian residents can get libdes from Eric Young's site:
ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/libdes-3.06.tar.gz
It is also available on many other sites (ask Archie).
I used libdes-3.06, but hopefully anything newer than that will work
also. Get the library, build and test it on your system, and install
it somewhere (typically /usr/local/lib and /usr/local/include).
You should now be ready to (re)compile the PPPD. Go to the pppd
subdirectory and make sure the Makefile contains "-DCHAPMS" in the
CFLAGS or COMPILE_FLAGS macro, and that the LIBS macro (or LDADD for
BSD systems) contains "-ldes". Depending on your system and where the
DES library was installed, you may also need to alter the include and
library paths used by your compiler.
Do a "make clean" and then a "make" to rebuild pppd. Assuming all
goes well, install the new pppd and move on to the CONFIGURATION
section.
MS-CHAP is enabled by default under Linux in pppd/Makefile.linux by
the line "CHAPMS=y".
CONFIGURATION

36
README.linux
View File

@@ -5,6 +5,7 @@
8 March 2001
for ppp-2.4.2
Updated for ppp-2.4.5, Sep 08
1. Introduction
---------------
@@ -13,8 +14,8 @@ The Linux PPP implementation includes both kernel and user-level
parts. This package contains the user-level part, which consists of
the PPP daemon (pppd) and associated utilities. In the past this
package has contained updated kernel drivers. This is no longer
necessary, as the current 2.2 and 2.4 kernel sources contain
up-to-date drivers.
necessary, as the current kernel sources contain up-to-date drivers
(and have done since the 2.4.x kernel series).
The Linux PPP implementation is capable of being used both for
initiating PPP connections (as a `client') or for handling incoming
@@ -47,7 +48,7 @@ the link down, when it negotiates a graceful disconnect.
2.1 Kernel driver
Assuming you are running a recent 2.2 or 2.4 (or later) series kernel,
Assuming you are running a recent 2.4 or 2.6 (or later) series kernel,
the kernel source code will contain an up-to-date kernel PPP driver.
If the PPP driver was included in your kernel configuration when your
kernel was built, then you only need to install the user-level
@@ -64,7 +65,7 @@ under /lib/modules and is loaded into the kernel when needed.
The 2.2 series kernels contain an older version of the kernel PPP
driver, one which doesn't support multilink. If you want multilink,
you need to run the latest 2.4 series kernel. The kernel PPP driver
you need to run a 2.4 or 2.6 series kernel. The kernel PPP driver
was completely rewritten for the 2.4 series kernels to support
multilink and to allow it to operate over diverse kinds of
communication medium (the 2.2 driver only operates over serial ports
@@ -94,7 +95,7 @@ If you obtained this package in .rpm or .deb format, you simply follow
the usual procedure for installing the package.
If you are using the .tar.gz form of this package, then cd into the
ppp-2.4.1b1 directory you obtained by unpacking the archive and issue
ppp-2.4.5 directory you obtained by unpacking the archive and issue
the following commands:
$ ./configure
@@ -111,34 +112,15 @@ files.
2.3 System setup for 2.4 kernels
Under the 2.4 series kernels, pppd needs to be able to open /dev/ppp,
character device (108,0). If you are using devfs (the device
filesystem), the /dev/ppp node will automagically appear when the
ppp_generic module is loaded, or at startup if ppp_generic is compiled
in.
character device (108,0). If you are using udev (as most distributions
do), the /dev/ppp node should be created by udevd.
If you have ppp_generic as a module, and you are using devfsd (the
devfs daemon), you will need to add a line like this to your
/etc/devfsd.conf:
LOOKUP ppp MODLOAD
Otherwise you will need to create a /dev/ppp device node with the
Otherwise you may need to create a /dev/ppp device node with the
commands:
# mknod /dev/ppp c 108 0
# chmod 600 /dev/ppp
If you use module autoloading and have PPP as a module, you will need
to add the following to your /etc/modules.conf or /etc/conf.modules:
alias /dev/ppp ppp_generic
alias char-major-108 ppp_generic
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
2.4 System setup under 2.2 series kernels

11
README.pppoe
View File

@@ -5,12 +5,13 @@
8 August 2001
for ppp-2.4.2
Updated for ppp-2.4.5 by Paul Mackerras, Sep 08
1. Introduction
---------------
This document describes the support for PPP over Ethernet (PPPoE)
included with this packages. It is assumed that the reader is
included with this package. It is assumed that the reader is
familiar with Linux PPP (as it pertains to tty/modem-based
connections). In particular, users of PPP in the Linux 2.2 series
kernels should ensure they are familiar with the changes to the PPP
@@ -19,7 +20,7 @@ PPPoE features.
If you are not familiar with PPP, I recommend looking at other
packages which include end-user configuration tools, such as Roaring
Penguin (http://www.roaringpenguin.com/pppoe)
Penguin (http://www.roaringpenguin.com/pppoe).
PPPoE is a protocol typically used by *DSL providers to manage IP
addresses and authenticate users. Essentially, PPPoE provides for a
@@ -42,10 +43,8 @@ This section is a quick guide for getting PPPoE working, to allow one
to connect to their ISP who is providing PPPoE based services.
1. Enable "Prompt for development and/or incomplete code/drivers" and
"PPP over Ethernet" in your kernel configuration. If you choose to
use the PPP over Ethernet driver as a module adding "alias
net-pf-24 pppoe" to /etc/modules.conf will enable auto-loading
of the modules.
"PPP over Ethernet" in your kernel configuration. Most distributions
will include the kernel PPPoE module by default.
2. Compile and install your kernel.

2
README.pwfd
View File

@@ -17,7 +17,7 @@ The passwordfd feature offers a simpler and more secure solution. The program
that starts the pppd opens a pipe and writes the password into it. The pppd
simply reads the password from that pipe.
This methods is used for quiet a while on SuSE Linux by the programs wvdial,
This methods is used for quite a while on SuSE Linux by the programs wvdial,
kppp and smpppd.

561
ppp.texi
View File

@@ -1,561 +0,0 @@
\input texinfo @c -*-texinfo-*-
@setfilename ppp.info
@settitle PPP
@iftex
@finalout
@end iftex
@ifinfo
@format
START-INFO-DIR-ENTRY
* PPP: (ppp). Point-to-Point Protocol.
END-INFO-DIR-ENTRY
@end format
@titlepage
@title PPP-2.x Users' Guide
@author by Paul Mackerras
@end titlepage
@node Top, Introduction, (dir), (dir)
@ifinfo
This file documents how to use the ppp-2.x package to set up network
links over serial lines with the Point-to-Point Protocol.
@end ifinfo
@menu
* Introduction:: Basic concepts of the Point-to-Point
Protocol and the ppp-2.x package.
* Installation:: How to compile and install the software.
* Configuration:: How to set up your system for
establishing a link to another system.
* Security:: Avoid creating security holes.
* Compression:: Using compression of various kinds
to improve throughput.
@end menu
@node Introduction, Installation, Top, Top
@chapter Introduction
The Point-to-Point Protocol (PPP) is the protocol of choice for
establishing network links over serial lines. This package (ppp-2.x)
provides an implementation of PPP which supports the Internet Protocols
(TCP/IP, UDP/IP, etc.) and which runs on a range of Unix workstations.
A typical use of PPP is to provide a network connection, via a modem,
between a workstation and an Internet Service Provider (ISP). When this
connection is established, the workstation is connected to the internet,
and applications running on the workstation can then make connections to
other hosts anywhere on the internet. This package can be used at
either or both ends of such a link.
Features of PPP include:
@itemize @bullet
@item
Multi-protocol support. The PPP packet encapsulation includes a
protocol field, allowing packets from many different protocols to be
multiplexed across a single link.
@item
Negotiation of link characteristics. During link establishment, the two
systems negotiate about the link configuration parameters, such as the
IP addresses of each end of the link.
@item
Authentication. Optionally, each system can be configured to require the
other system to authenticate itself. In this way, access can be
restricted to authorized systems.
@item
Transparency. On asynchronous serial lines, PPP can be configured to
transmit certain characters as a two-character escape sequence.
@item
Compression. PPP includes support for various kinds of compression to
be applied to the packets before they are transmitted.
@end itemize
The ppp-2.x software consists of two parts:
@itemize @bullet
@item
Kernel code, which establishes a network interface and passes packets
between the serial port, the kernel networking code and the PPP daemon
(@file{pppd}). This code is implemented using STREAMS modules on
Solaris 2, SunOS 4.x, AIX 4.1 and OSF/1, and as a tty line discipline
under Ultrix, NextStep, NetBSD, FreeBSD, and Linux.
@item
The PPP daemon (@file{pppd}), which negotiates with the peer to
establish the link and sets up the ppp network interface. Pppd includes
support for authentication. It can authenticate itself to the other
system and/or require the other system to authenticate itself, so that
you can control which other systems may make a PPP connection and what
IP addresses they may use.
@end itemize
@menu
* PPP Concepts:: Basic concepts and terms used with PPP.
* PPP packet format:: How data is packaged up for transmission.
* LCP negotiation:: The parameters which are negotiated
using the Link Control Protocol.
* IPCP negotiation:: The parameters which are negotiated
using the IP Control Protocol.
@end menu
@node PPP Concepts, PPP packet format, Introduction, Introduction
@section PPP Concepts
To use PPP to provide a network connection between two machines, there
must be some way that a stream of bytes, or characters, can be passed
from one to the other, in both directions independently. We refer to
this as the ``serial link''. Very often the serial link involves
asynchronous communications ports and modems, but other kinds of serial
link are possible.
The serial link must transmit (at least) 8 bits per character; PPP
cannot work over a serial link which transmits only 7 bits per
character. However, it need not transmit all byte values transparently.
PPP has a mechanism to avoid sending certain characters if it is known
that the some element of the serial link interprets them specially. For
example, the DC1 and DC3 ASCII characters (control-Q and control-S) may
be trapped by a modem if it is set for ``software'' flow control. PPP
can send these characters as a two-character ``escape'' sequence. The
set of characters which are to be transmitted as an escape sequence is
represented in an ``async control character map'' (ACCM). The ``async''
part refers to the fact that this facility is used for asynchronous
serial links. For synchronous serial connections, the HDLC bit-stuffing
procedure is used instead.
The two systems connected by the serial link are called ``peers''. When
we are talking from the point of view of one of the systems, the other
is often referred to as ``the peer''. Sometimes we may refer to one
system as a ``client'' and the other as a ``server''. This distinction
refers mainly to the way the serial link is set up; usually the client
is the peer that initiates the connection, for example by dialling the
server with its modem.
During the lifetime of a PPP connection, it proceeds through several
phases:
@enumerate
@item
Serial link establishment. In this phase, the serial link is set up and
PPP protocol software is attached to each end of the serial link. The
precise steps involved in doing this vary greatly, depending on the
nature of the serial link. For the common case of modems connected
through the telephone network, this involves first sending commands to
the modem to cause it to dial the remote system. When the remote system
answers, the local system usually has to supply a username and password,
and then issue a command to invoke PPP software on the remote system.
The ``chat'' program supplied with ppp-2.x provides a way to automate a
dialog with the modem and the remote system. This phase is not
standardized; it is outside the scope of the PPP protocol
specifications.
@item
Link Control Protocol (LCP) negotiation. In this phase, the peers send
LCP packets to each other to negotiate various parameters of the
connection, such as the ACCM to be used in each direction, whether
authentication is required, and whether or not to use various forms of
compression. When the peers reach agreement on these parameters, LCP is
said to be ``up''.
@item
Authentication. If one (or both) of the peers requires the other
peer to authenticate itself, that occurs next. If one of the peers
cannot successfully authenticate itself, the other peer terminates the
link.
@item
Network Control Protocol (NCP) negotiation. PPP can potentially support
several different network protocols, although IP is the only network
protocol (NP) supported by the ppp-2.x package. Each NP has an
associated NCP defined for it, which is used to negotiate the specific
parameters which affect that NP. For example, the IP Control Protocol
(IPCP) is used to negotiate the IP addresses for each end of the link,
and whether the TCP header compression method described by Van Jacobsen
in RFC 1144 (``VJ compression'') is to be used.
@item
Network communication. When each NCP has successfully negotiated the
parameters for its NP, that NCP is said to be ``up''. At that point,
the PPP link is made available for data traffic from that NP. For
example, when IPCP comes up, the PPP link is then available for carrying
IP packets (which of course includes packets from those protocols which
are layered above IP, such as TCP, UDP, etc.)
@item
Termination. When the link is no longer required, it is terminated.
Usually this involves an exchange of LCP packets so that one peer can
notify the other that it is shutting down the link, enabling both peers
to shut down in an orderly manner. But of course there are occasions
when the link terminates because the serial link is interrupted, for
example, when a modem loses carrier and hangs up.
@end enumerate
The protocols in the PPP family are produced by the Point-to-Point
Working Group of the Internet Engineering Task Force, and are specified
in RFC (Request for Comments) documents, available by anonymous FTP from
several sites.
PPP is defined in several RFCs, in
particular RFCs 1661, 1662, and 1334. IPCP is defined in RFC 1332.
Other RFCs describe the control protocols for other network protocols
(e.g., DECnet, OSI, Appletalk). RFCs are available by anonymous FTP
from several sites including nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, and munnari.oz.au.
@node PPP packet format, LCP negotiation, PPP Concepts, Introduction
@section PPP packet format
PPP transmits packets over the serial link using a simple encapsulation
scheme. First, a two-byte PPP Protocol field is inserted before the
data to be sent. The value in this field identifies
which higher-level protocol (either a network protocol such as IP or a
PPP control protocol such as LCP) should receive the data in the packet.
By default, a one-byte Address field with the value 0xFF, and a one-byte
Control field with the value 0x03, are inserted before the PPP Protocol
field (apparently this is supposed to provide compatibility with HDLC,
in case there is a synchronous to asynchronous converter in the serial
link).
On slow serial links, these fields can be compressed down to one byte in
most cases. The PPP Address and Control fields are compressed by simply
omitting them (``address/control compression''). The PPP Protocol field
values are chosen so that bit 0 (the least-significant bit) of the first
(most significant) byte is always 0, and bit 0 of the second byte is
always 1. The PPP Protocol field can be compressed by omitting the
first byte, provided that it is 0 (``protocol compression''). The
values for this field are assigned so that the first byte is zero for
all of the commonly-used network protocols. For example, the PPP
Protocol field value for IP is 0x21.
For asynchronous serial links, which do not provide any packet framing
or transparency, a further encapsulation is used as follows. First a
16-bit Frame Check Sequence (FCS) is computed over the packet to be
sent, and appended as two bytes to the end of the packet.
Then each byte of the packet is examined, and if it contains one of the
characters which are to be escaped, it is replaced by a two byte
sequence: the 0x7d character '}', followed by the character with bit 5
inverted. For example, the control-C character (0x03) could be replaced
by the two-byte sequence 0x7d, 0x23 ('}#'). The 0x7d and 0x7e ('~')
characters are always escaped, and the 0x5e ('^') character may not be
escaped.
Finally, a ``flag'' character (0x7e, '~') is inserted at the beginning
and end of the packet to mark the packet boundaries. The initial flag
may be omitted if this packet immediately follows another packet, as the
ending flag for the previous packet can serve as the beginning flag of
this packet.
@node LCP negotiation, IPCP negotiation, PPP packet format, Introduction
@section LCP negotiation
The LCP negotiation process actually involves two sets of negotiations,
one for each direction of the PPP connection. Thus A will send B
packets (``Configure-Requests'') describing what characteristics A would
like to have apply to the B -> A direction of the link, that is, to the
packets that A will receive. Similarly B will send A packets describing
the characteristics it would like to have apply to the packets it will
be receiving. These characteristics need not necessarily be the same in
both directions.
The parameters which are negotiated for each direction of the connection
using LCP are:
@itemize @bullet
@item
Maximum Receive Unit (MRU): indicates the maximum packet size which we
are prepared to receive (specifically the maximum size of the
data portion of the packet). The default value is 1500, but on
slow serial links, smaller values give better response. The choice of
MRU is discussed below (see xxx).
@item
Async Control Character Map (ACCM): indicates the set of control
characters (characters with ASCII values in the range 0 - 31) which we
wish to receive in escaped form. The default is that the sender should
escape all characters in the range 0 - 31.
@item
Authentication Protocol: indicates which protocol we would like the peer
to use to authenticate itself. Common choices are the Password
Authentication Protocol (PAP) and the Cryptographic Handshake
Authentication Protocol (CHAP).
@item
Quality Protocol: indicates which protocol which we would like the peer
to use to send us link quality reports. The ppp-2.x package does not
currently support link quality reports.
@item
Magic Number: a randomly-chosen number, different from the peer's magic
number. If we persistently receive our own magic number in the peer's
configure-request packets, then we can conclude that the serial link is
looped back.
@item
Protocol Field Compression: indicates that we wish the peer to compress
the PPP Protocol field to one byte, where possible, in the packets it
sends.
@item
Address/Control Field Compression: indicates that we wish the peer to
compress the PPP Address/Control fields (by simply omitting them) in the
packets it sends.
@end itemize
@node IPCP negotiation, , LCP negotiation, Introduction
@section IPCP negotiation
The IPCP negotiation process is very similar to the LCP negotiation
process, except that of course different parameters are negotiated.
The parameters which are negotiated using IPCP are:
@itemize @bullet
@item
IP Address: the IP address (32-bit host IP number) which we plan to use
as the local address for our end of the link.
@item
TCP header compression: indicates (a) that we wish the peer to compress
the TCP/IP headers of TCP/IP packets that it sends, using the Van
Jacobson algorithm as described in RFC1144; (b) the maximum slot ID that
we wish the peer to use, and (c) whether we are prepared to accept
packets with the slot ID field compressed (omitted).
With Van Jacobson (VJ) compression, the receiver and transmitter (for
one direction of the connection) both keep a table, with a certain
number of ``slots'', where each slot holds the TCP/IP header of the most
recently transmitted packet for one TCP connection. If a packet is to
be transmitted for a TCP connection which does not have a slot currently
allocated, the VJ scheme will allocate one of the slots and send the
entire TCP/IP header, together with the slot number. For many packets,
there will be a slot already allocated for the TCP connection, and the
VJ scheme will then often be able to replace the entire TCP/IP header
with a much smaller compressed header (typically only 3 - 7 bytes)
describing which fields of the TCP/IP header have changed, and by how
much. If there are many more active connections than slots, the
efficiency of the VJ scheme will drop, because it will not be able to
send compressed headers as often.
Usually the compressed header includes a one-byte slot index, indicating
which TCP connection the packet is for. It is possible to reduce the
header size by omitting the slot index when the packet has the same slot
index as the previous packet. However, this introduces a danger if the
lower levels of the PPP software can sometimes drop damaged packets
without informing the VJ decompressor, as it may then assume the wrong
slot index for packets which have the slot index field omitted. With
the ppp-2.x software, however, the probability of this happening is
generally very small (see xxx).
@end itemize
@node Installation, Configuration, Introduction, Top
@chapter Installation
Because ppp-2.x includes code which must be incorporated into the
kernel, its installation process is necessarily quite heavily
system-dependent. In addition, you will require super-user privileges
(root access) to install the code.
Some systems provide a ``modload'' facility, which allows you to load
new code into a running kernel without relinking the kernel or
rebooting. Under Solaris 2, SunOS 4.x, Linux, OSF/1 and NextStep, this
is the recommended (or only) way to install the kernel portion of the
ppp-2.x package.
Under the remaining supported operating systems (NetBSD, FreeBSD,
Ultrix), it is necessary to go through the process of creating a new
kernel image and reboot. (Note that NetBSD and FreeBSD have a modload
facility, but ppp-2.x is currently not configured to take advantage of
it.)
Detailed installation instructions for each operating system are
contained in the README files in the ppp-2.x distribution. In general,
the process involves executing the commands @samp{./configure},
@samp{make} and (as root) @samp{make install} in the ppp-2.x
distribution directory. (The Linux port requires the installation of
some header files before compiling; see README.linux for details.)
@node Configuration, Security, Installation, Top
@chapter Configuration
Once the ppp-2.x software is installed, you need to configure your
system for the particular PPP connections you wish to allow. Typically,
the elements you need to configure are:
@itemize @bullet
@item
How the serial link is established and how pppd gets invoked.
@item
Setting up syslog to log messages from pppd to the console and/or
system log files.
@item
Pppd options to be used.
@item
Authentication secrets to use in authenticating us to the peer
and/or the peer to us.
@item
The IP addresses for each end of the link.
@end itemize
In most cases, the system you are configuring will either be a
@dfn{client} system, actively initiating a PPP connection on user
request, or it will be a @dfn{server} system, passively waiting for
connections from client systems. Other arrangements are possible, but
the instructions in this system assume that you are configuring either a
client or a server.
These instructions also assume that the serial link involves a serial
communications port (that is, a tty device), since pppd requires a
serial port.
@menu
* Client machines::
* Server machines::
* Setting up syslog::
* Pppd options::
* Authentication secrets files::
* IP Addresses::
@end menu
@node Client machines, Server machines, Configuration, Configuration
@section Client machines
On a client machine, the way that the user requests that a connection be
established is by running pppd, either directly or through a shell
script. Pppd should be given the name of the serial port to use as an
option. In this mode, pppd will fork and detach itself from its
controlling terminal, so that the shell will return to its prompt. (If
this behaviour is not desired, use the -detach option.)
Usually, the connect option should also be used. The connect option
takes an argument which is a command to run to establish the serial link
and invoke PPP software on the remote machine. This command is run with
its standard input and standard output connected to the serial port.
Giving the connect option to pppd also has the side-effect of causing
pppd to open the serial port without waiting for the modem carrier
detect signal.
The process of establishing the serial link often involves a dialog. If
the serial port is connected to a modem, we first need to send some
commands to the modem to configure it and dial the remote system. Often
there is then a dialog with the remote system to supply a username and
password. The @file{chat} program supplied with the ppp-2.x package is
useful for automating such dialogs. Chat uses a @dfn{script} consisting
of alternately strings to expect to receive on the serial port, and
strings to send on the serial port. The script can also specify strings
which indicate an error and abort the dialog.
@node Server machines, , Client machines, Configuration
@section Server machines
There are generally three ways in which a server machine can be set up
to allow client machines to establish a PPP link:
@enumerate
@item
Client machines log in as regular users (often via a serial port
connected to a modem, but possibly through a telnet or rlogin session)
and then run pppd as a shell command.
@item
Client machines log in using a username whose login shell is pppd
or a script which runs pppd.
@item
Client machines connect to a serial port which has a pppd running
permanently on it (instead of a "getty" or other program providing a
login service).
@end enumerate
Method 1 is very simple to set up, and is useful where existing users of
a system have remote machines (for example at home) from which they want
to establish a PPP connection from time to time. Methods 2 and 3
possibly have a security advantage in that they do not allow PPP client
systems access to a shell. Method 2 allows regular logins and PPP
connections on the same port, while with method 3, would-be crackers may
well be frustrated (unless they speak fluent PPP).
With any of these methods, I strongly recommend that you configure PPP
to require authentication from the client, by including the `auth'
option in the /etc/ppp/options file.
@node Setting up syslog, , Server machines, Configuration
@section Setting up syslog
Pppd uses the @file{syslog} facility to report information about the
state of the connection, as does @file{chat}. It is useful to set up
syslog to print some of these messages on the console, and to record
most of them to a file. The messages from pppd are logged with facility
@samp{daemon} and one of three levels:
@itemize @bullet
@item
@samp{notice} for messages about important events such as the
connection becoming available for IP traffic and the local and remote IP
addresses in use.
@item
@samp{info} for messages about less important events, such as
detecting a modem hangup.
@item
@samp{debug} for messages which are of use in working out why the
connection is not working properly.
@end itemize
The messages from chat are logged with facility @samp{local2} and level
@samp{debug}.
Syslog is controlled by the syslog configuration file
@file{/etc/syslog.conf}. Generally the standard configuration will log
facility @samp{daemon} messages with level @samp{notice} and above to a
system log file such as @file{/var/log/syslog} (the name may vary on
different systems). I find it useful to have the notice level messages
from pppd displayed on the console, and all messages from pppd and chat
logged to a file such as @file{/etc/ppp/log}. To achieve this,
find the line in /etc/syslog.conf which has /dev/console
on the right-hand side, and add `daemon.notice' on the left. This
line should end up something like this:
@example
*.err;kern.debug;auth.notice;mail.crit;daemon.notice /dev/console
@end example
And add a line like this:
@example
daemon,local2.debug /etc/ppp/log
@end example
The space between the left and right hand sides is one or more tabs, not
spaces, and there are no tabs or spaces at the beginning of the line.
You will need to create an empty @file{/etc/ppp/log} file; syslogd will
not create it. Once you have modified @file{/etc/syslog.conf}, you need
to either reboot or notify syslogd to re-read the file. On most
systems, you notify syslogd by sending it a SIGHUP signal. Syslogd's
process ID is usually stored in a file such as @file{/etc/syslogd.pid}
or @file{/var/run/syslog.pid}. Thus you can notify syslogd to re-read
the file by executing a command such as:
@example
kill -HUP `cat /etc/syslogd.pid`
@end example
@node Pppd options, , Setting up syslog, Configuration
@section Pppd options
@node Authentication secrets files, , Pppd options, Configuration
@section Authentication secrets files
@node IP Addresses, , Authentication secrets files, Configuration
@section IP Addresses
@node Security, Compression, Configuration, Top
@chapter Security
@node Compression, , Security, Top
@chapter Compression
@bye