--- /dev/null
+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.
+
+
+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:
+
+ SunOS 4.x README.sun
+ NetBSD, FreeBSD README.bsd
+ Ultrix 4.x README.ultrix
+ Linux README.linux
+ OSF/1 README.osf
+ AIX 4.x README.aix4
+ NeXTStep README.next
+
+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.
+
+
+What is new in ppp-2.2.
+***********************
+
+* More systems are now supported:
+
+ AIX 4, thanks to Charlie Wick (cwick@quaver.urbana.mcd.mot.com)
+ 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)
+
+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.
+
+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
+ osf1/ppp_async.c
+ osf1/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
--- /dev/null
+
+AIX 4.1 support is ported from the SunOS code for ppp 2.2. It requires
+a streams-based tty and will not work on AIX 3.2. This is the first
+release of this package for AIX. It is provided free and without warranty
+of any kind. I can't make any promise to support this, but if you e-mail
+me with problems I'll try to help you. Please let me know about any bugs
+you might find.
+
+Introduction
+
+ PPP implements TCP/IP through serial connections. In ppp 2.2, an
+ interface is established by running the program 'pppd'. pppd opens
+ a serial connection, negotiates link attributes with the peer and
+ configures a TCP/IP interface. The interface remains up as long as
+ the peer stays up and 'pppd' remains running. There are no SMIT menus
+ and ppp interfaces can not be defined through ifconfig. An interface
+ can be brought down by killing pppd.
+
+ The program 'chat' processes send-expect sequences similar to UUCP
+ Dialers commands or a Systems chat string. It can be used to dial
+ a modem.
+
+ 'pppstats' prints interface statistics similar to netstat. Some of the
+ statistics are the same as netstat but pppstat also provides additional
+ info specific to ppp interfaces.
+
+Installation
+
+ First execute the following commands in the ppp-2.2 directory:
+
+ ./configure
+ make install (you need to be root for this)
+
+ By default, pppd, chat and pppstats are placed in /usr/sbin and the
+ streams modules in /usr/lib/drivers. The modules are loaded by the following
+ 'strload' commands.
+
+ strload -m /usr/lib/drivers/ppp_if
+ strload -m /usr/lib/drivers/ppp_comp
+ strload -m /usr/lib/drivers/ppp_async
+
+ 'make install' appends the strloads to /etc/rc.tcpip so the modules
+ will be loaded at boot. A 'pppd' command can be added to start
+ up an interface.
+
+ 'make install' will also create /etc/ppp/options containing the option
+ 'lock' only (lock tty device when in use). Any other options which will
+ always be used should be added by hand.
+
+ Man pages for pppd and pppstats are installed.
+
+Examples
+
+ To answer a modem and accept connections, use something like
+
+ pppd tty1 myhostname:remotehostname persist
+
+ This will wait for calls on tty1 and establish a connection with any
+ ppp caller. The server will use myhostname and tell the caller
+ to use remotehostname. The persist option tells pppd to remain
+ active and accept another connection after the call terminates.
+ You can use the 'auth' option to force callers to authenticate
+ themselves. See pppd man page for details of authentication protocols.
+
+ To dial in to a user account and start PPP, use something like
+
+ pppd tty1 myhostname: connect 'chat -f /etc/ppp/chat-script'
+
+ where the file /etc/ppp/chat-script should contain something like
+
+ "" ATDT5551212 CONNECT "" ogin: myname sword: mypassword $ pppd
+
+ This command uses the chat program to dial the modem, log in and
+ start pppd on the server. No ttyname is needed when starting pppd on the
+ server side because pppd will attach to the current terminal (the tty line),
+ if no device is specified. Any pppd options needed can be set in ~/.ppprc
+ on the called system.
+
+ The chat -v option may be helpful in debugging connection failures. The
+ chat output and other debug messages are sent to syslog. You may need
+ to edit /etc/syslog.conf and "refresh -s syslogd" to see the debug messages.
+
+ The simplest way to allow a remote dial-in host to use your network is
+ to use the 'proxyarp' option on the server. This will cause the
+ server to publish an arp entry with the remote's IP address and the
+ server's hardware address. The remote will then appear to be part of
+ local network to other hosts. The address/netmask used by the remote
+ must be suitable for the subnet you wish to connect to. If the remote
+ is a standalone system, or has no other default route, use the
+ 'defaultroute' option when dialing in. This will create a default route
+ on the remote system through the server. If the remote is on another
+ local network, you might not want this because it could conflict with
+ an existing default route.
+
+ These are just a few examples to help the new user get started. The
+ man page for pppd describes all the options in detail.
+
+ Charlie Wick
+ cwick@prairienet.org
+
--- /dev/null
+Installation instructions for installing ppp-2.2 on FreeBSD and
+NetBSD systems.
+
+This package supports NetBSD-1.0 and FreeBSD-2.0. It should work
+on later systems (it works on NetBSD-current as of this writing).
+Modloading is not yet supported.
+
+I have code which should work on earlier systems (386BSD, NetBSD-0.9,
+FreeBSD-1.1.5.1, etc.), but it is not included in this package because
+I have no way to test or support it. If you are committed to one of
+these earlier versions and you are willing to try out some code
+without needing major hand-holding, contact me (paulus@cs.anu.edu.au).
+
+To install PPP, you need to rebuild your kernel to include the latest
+version of the PPP driver, as well as compiling and installing the
+user-level applications: pppd, pppstats and chat. The user-level
+applications can be compiled and installed either before or after you
+reboot with the new kernel (you'll have to reboot with the new kernel
+before you can run them, of course).
+
+The following commands should compile and install the user-level
+applications (in the ppp-2.2 directory):
+
+ ./configure
+ make
+ make install (you need to be root for this)
+
+The process of updating the kernel source files is now largely
+automated. In the ppp-2.2 directory, issue the command:
+
+ make kernel
+
+(you probably need to be root for this). This will copy new versions
+of several files into /sys, patch other files, and finally give you
+instructions about modifying your kernel configuration file (if
+necessary), rebuilding the kernel and rebooting.
+
+If you want to do the process by hand, read on...
+
+
+Updating the kernel ppp code.
+-----------------------------
+
+You need to update several files in the /sys/net directory, and patch
+some other files under /sys.
+
+For NetBSD-1.0, copy the following files to /sys/net:
+
+ net/if_ppp.h
+ net/ppp-comp.h
+ net/ppp_defs.h
+ netbsd/bsd-comp.c
+ netbsd/if_ppp.c
+ netbsd/if_pppvar.h
+ netbsd/netisr.h
+ netbsd/ppp_tty.c
+ netbsd/slcompress.c
+ netbsd/slcompress.h
+
+You then need to patch /sys/conf/files and /sys/conf/files.newconf
+using the commands:
+
+ patch -p -N -d /sys/conf <netbsd/files.patch
+ patch -p -N -d /sys/conf <netbsd/files.newconf.patch
+
+The next step is to patch the file containing the code which
+dispatches software interrupts. Unfortunately, this code is in the
+architecture-dependent files, so the file to patch depends on which
+NetBSD port you are using:
+
+Port File to patch Patch file
+---- ------------- ----------
+amiga /sys/arch/amiga/amiga/machdep.c netbsd/arch/amiga/machdep.c.patch
+hp300 /sys/arch/hp300/hp300/machdep.c netbsd/arch/hp300/machdep.c.patch
+i386 /sys/arch/i386/isa/icu.s netbsd/arch/i386/icu.s.patch
+mac68k /sys/arch/mac68k/mac68k/machdep.c netbsd/arch/mac68k/machdep.c.patch
+pc532 /sys/arch/pc532/pc532/locore.s netbsd/arch/pc532/locore.s.patch
+pmax /sys/arch/pmax/pmax/trap.c netbsd/arch/pmax/trap.c.patch
+sparc /sys/arch/sparc/sparc/intr.c netbsd/arch/sparc/intr.c.patch
+sun3 /sys/arch/sun3/sun3/isr.c netbsd/arch/sun3/isr.c.patch
+
+To do the patch, you would use a command something like this:
+
+ patch -p -d /sys/arch/i386/isa <netbsd/arch/i386/icu.s.patch
+
+
+For FreeBSD-2.0, copy the following files to /sys/net:
+
+ net/if_ppp.h
+ net/ppp-comp.h
+ net/ppp_defs.h
+ freebsd-2.0/bsd-comp.c
+ freebsd-2.0/if_ppp.c
+ freebsd-2.0/if_pppvar.h
+ freebsd-2.0/ppp_tty.c
+ freebsd-2.0/pppcompress.c
+ freebsd-2.0/pppcompress.h
+
+You then need to patch /sys/conf/files using the command:
+
+ patch -p -N -d /sys/conf <freebsd-2.0/files.patch
+
+
+Configuring and making the new kernel.
+--------------------------------------
+
+First, make sure that the configuration file you are using includes a
+line something like
+
+ pseudo-device ppp 2
+
+If it doesn't, add one. The `2' is the number of ppp interfaces to
+configure, that is, the maximum number of simultaneous ppp connections
+you will be able to have; change it as required.
+
+Next, run config or config.new in the directory containing the
+configuration file, giving the configuration file name as an argument.
+Then cd to the compilation directory and make the kernel. For the
+i386 port of NetBSD, with a configuration file called CONF, this
+involves the following commands:
+
+ cd /sys/arch/i386/conf
+ /usr/sbin/config CONF
+ cd ../compile/CONF
+ make
+
+For FreeBSD, the commands are similar except for different
+directories:
+
+ cd /sys/i386/conf
+ /usr/sbin/config CONF
+ cd ../../compile/CONF
+ make
+
+The result should be a new kernel image (usually called `netbsd' under
+NetBSD, `kernel' under FreeBSD). Save a copy of the kernel image
+you're currently using, copy the new kernel image file to /, and
+reboot.
--- /dev/null
+
+PPP for Linux Version 0.2.8
+============= based on
+ ppp-2.1.0
+ May 1994
+
+Michael Callahan callahan@maths.ox.ac.uk
+Al Longyear longyear@netcom.com
+
+ Contents:
+ INTRODUCTION
+ CREDITS
+ FUTURE PLANS
+ INSTALLATION
+ GENERAL NETWORK CONFIGURATION
+ CONNECTING TO A PPP SERVER
+ IF IT WORKS
+ IF IT DOESN'T WORK
+ IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
+ DYNAMIC ADDRESS ASSIGNMENT
+ SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
+ ADDING MORE PPP CHANNELS
+ CHANGES FROM LINUX PPP 0.1.x
+ CONCLUSION
+
+
+INTRODUCTION
+
+This is a PPP driver for Linux. It has been used by many people and
+seems to be quite stable. It is capable of being used either as a
+'client'--for connecting a Linux machine to a local Internet provider,
+for example--or as a 'server'--allowing a Linux machine with a modem
+and an Ethernet connection to the Internet to provide dial-in PPP
+links. (In fact, the PPP protocol does not make the distinction
+between client and server, but this is the way people often think
+about it.)
+
+The PPP protocol consists of two parts. One is a scheme for framing
+and encoding packets, the other is a series of protocols called LCP,
+IPCP, UPAP and CHAP, for negotiating link options and for
+authentication. This package similarly consists of two parts: a
+kernel module which handles PPP's low-level framing protocol, and a
+user-level program called pppd which implements PPP's negotiation
+protocols.
+
+The kernel module assembles/disassembles PPP frames, handles error
+detection, and forwards packets between the serial port and either the
+kernel network code or the user-level program pppd. IP packets go
+directly to the kernel network code. So once pppd has negotiated the
+link, it in practice lies completely dormant until you want to take
+the link down, when it negotiates a graceful disconnect.
+
+CREDITS
+
+I (MJC) wrote the original kernel driver from scratch. Laurence
+Culhane and Fred van Kempen's slip.c was priceless as a model (a
+perusal of the files will reveal that I often mimicked what slip.c
+did). Otherwise I just implemented what pppd needs, using RFC1331 as
+a guide. For the most part, the Linux driver provides the same
+interface as the free 386BSD and SunOS drivers. The exception is that
+Linux has no support for asynchronous I/O, so I hacked an ioctl into
+the PPP kernel module that provides a signal when packets appear and
+made pppd use this instead.
+
+Al Longyear ported version 2.0.4 of pppd (from the free package
+ppp-2.0.4) to Linux. He also provided several enhancements to both
+the kernel driver and the OS-independent part of pppd. His
+contributions to Linux PPP have been immense, and so this release
+is being distributed over both our names.
+
+The pppd program comes from the free distribution of PPP for Suns and
+386BSD machines, maintained by Paul Mackerras. This package lists
+"thanks to" Brad Parker, Greg Christy, Drew D. Perkins, Rick Adams and
+Chris Torek.
+
+
+FUTURE PLANS
+
+The main missing feature is the ability to fire up a PPP connection
+automatically when a packet destined for the remote host is generated
+("demand-dialing"). Work is progressing on this, but it involves some
+nontrivial design issues.
+
+
+INSTALLATION
+
+This version of PPP has been tested on 1.0.x (x=0..9) and 1.1.x
+(x=0..14) kernels. It will probably not work on kernels much earlier
+than this due to a change in the routing code. If you have an earlier
+kernel, please upgrade.
+
+joining the PPP channel of linux-activists:
+
+ This isn't really part of installation, but if you DO use
+ Linux PPP you should do this. Send a message with the line
+ X-Mn-Admin: join PPP
+ contained in the body to linux-activists-request@niksula.hut.fi
+ You can send to the list by mailing to
+ linux-activists@niksula.hut.fi and putting the line
+ X-Mn-Key: PPP
+ at the start of your message.
+
+ The advantage of subscribing is that you'll be informed of
+ updates and patches, and you'll be able to draw on the
+ experience of many PPP users. If you have a problem, I may not
+ be able to diagnose it, but someone else may have solved it
+ already.
+
+ Note also that I do not read the linux Usenet newsgroups
+ regularly enough to catch any discussions of PPP; if you want to
+ reach the PPP audience you should join the linux-activists
+ channel.
+
+ To leave the PPP mailing list :-(, send a message with the line
+ X-Mn-Admin: leave PPP
+ to linux-activists-request.
+
+kernel driver installation:
+
+ This depends on the kernel version you're using.
+
+ Since 1.1.14, Linux kernels have had built-in support for PPP.
+ You'll be asked whether you want PPP when you run "make config".
+ It's as easy as that.
+
+ In 1.1.13, PPP is there but the PPP line in config.in is
+ commented out. If you have 1.1.13, you probably should just
+ upgrade anyway.
+
+ Kernel versions prior to 1.1.13 (including all 1.0.x kernels)
+ have had (hidden) support for PPP in the kernel configuration
+ setup for quite some time. Adding the PPP kernel driver is
+ easy:
+
+ 1) copy ppp.c from the linux subdirectory of the distribution
+ to drivers/net and ppp.h to include/linux
+ 2) uncomment the CONFIG_PPP line in config.in
+ 3) if you are using 1.1.3 or earlier (including 1.0.x):
+ uncomment the line in ppp.c that begins
+ /* #define NET02D
+ by removing the "/* " characters
+ 4) in the top level of the kernel source
+ make config
+ make dep
+ make
+
+ Reboot with the new kernel. At startup, you should see
+ something line this:
+
+ PPP: version 0.2.8 (4 channels)
+ TCP compression code copyright 1989 Regents of the University of California
+ PPP line discipline registered.
+
+ (If you want more than 4 channels, see the section "ADDING MORE
+ PPP CHANNELS" below.)
+
+ Now, try looking at the contents of /proc/net/dev. It should
+ look something like this:
+
+ Inter-| Receive | Transmit
+ face |packets errs drop fifo frame|packets errs drop fifo colls carrier
+ lo: 0 0 0 0 0 0 0 0 0 0 0
+ ppp0: 0 0 0 0 0 0 0 0 0 0 0
+ ppp1: 0 0 0 0 0 0 0 0 0 0 0
+ ppp2: 0 0 0 0 0 0 0 0 0 0 0
+ ppp3: 0 0 0 0 0 0 0 0 0 0 0
+
+ This indicates that the driver is successfully installed.
+
+ (Of course, you should keep a kernel without PPP around, in case
+ something goes wrong.)
+
+pppd installation:
+
+ First execute the following commands (in the ppp-2.2 directory):
+
+ ./configure
+ make
+
+ This will make the pppd and chat programs.
+
+ To install, type 'make install' (in the ppp-2.2 directory).
+ This will put chat and pppd binaries in /usr/etc
+ and the pppd.8 manual page in /usr/man/man8.
+
+ pppd needs to be run as root. You can either make it setuid
+ root or just use it when you are root. 'make install' will try
+ to install it setuid root. Making pppd setuid root is
+ convenient for a single-user machine, but has security
+ implications which you should investigate carefully before
+ making it available on a multiuser machine.
+
+GENERAL NETWORK CONFIGURATION
+
+Since many people don't use the Linux networking code at all until
+they get a PPP link, this section describes generally what's needed to
+get things running. In principle none of this is special to PPP. For
+more details, you should consult the relevant Linux HOWTOs. If you
+already understand network setup, you can skip this section.
+
+The first file that requires attention is the rc script that does
+network configuration at boot time, called /etc/rc.net or
+/etc/rc.d/rc.net.{1,2} or something similar, depending on your Linux
+distribution. This file should 'ifconfig' the loopback interface lo,
+and should add an interface route for it. These lines might look
+something like this:
+ $CONFIG lo 127.0.0.1
+ $ROUTE add loopback
+or
+ /sbin/ifconfig lo 127.0.0.1
+ /sbin/route add 127.0.0.1
+
+However, it should *not* config an ethernet card or install any other
+routes (unless you actually have an ethernet card, in which case I'll
+assume you know what to do). Many distributions will provide scripts
+that expect you to have an ethernet card.
+
+You also need to decide whether you want to allow incoming
+telnet/ftp/finger, etc. If so, you should have the rc startup script
+run the 'inetd' daemon.
+
+Next, you should set up /etc/hosts to have two lines. The first
+should just give the loopback or localhost address and the second
+should give your own host name and the IP address your PPP connection
+will use. For example:
+ 127.0.0.1 loopback localhost # useful aliases
+ 192.1.1.17 billpc.whitehouse.gov bill # my hostname
+where my IP address is 192.1.1.17 and my hostname is
+billpc.whitehouse.gov. (Not really, you understand.) If your PPP
+server does dynamic IP address assignment, give a guess as to an
+address you might get (see also "Dynamic Address Assignment" below).
+
+Finally, you need to configure the domain name system by putting
+appropriate lines in /etc/resolv.conf . It should look something like
+this:
+ domain whitehouse.gov
+ nameserver 192.1.2.1
+ nameserver 192.1.2.10
+Assuming there are nameservers at 192.1.2.1 and 192.1.2.10, then when
+you get connected with PPP, you can reach hosts whose full names are
+'hillarypc.whitehouse.gov' and 'chelseapc.whitehouse.gov' by the names
+'hillarypc' and 'chelseapc'. You can probably find out the right
+domain name to use and the IP numbers of nameservers from whoever's
+providing your PPP link.
+
+CONNECTING TO A PPP SERVER
+
+To use PPP, you invoke the pppd program with appropriate options.
+Everything you need to know is contained in the pppd(8) manual page.
+However, it's useful to see some examples:
+
+Example 1: A simple dial-up connection.
+
+Here's a command for connecting to a PPP server by modem.
+
+ pppd connect 'chat -v -f chat-script' \
+ /dev/cua1 38400 -detach debug crtscts modem defaultroute 192.1.1.17:
+
+where the file chat-script contains:
+
+ "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater
+
+Going through pppd's options in order:
+ connect 'chat ...' This gives a command to run to contact the
+ PPP server. Here the supplied 'chat' program is used to dial a
+ remote computer. The whole command is enclosed in single quotes
+ because pppd expects a one-word argument for the 'connect' option.
+ The options to 'chat' itself are:
+ -v verbose mode; log what we do to syslog
+ -f chat-script expect-send strings are in the file chat-script
+ The strings for chat to look for and to send are stored in the
+ chat-script file. The strings can be put on the chat command line,
+ but this is not recommended because it makes your password visible
+ to anyone running ps while chat is running. The strings are:
+ "" don't wait for any prompt, but instead...
+ ATDT5551212 dial the modem, then
+ CONNECT wait for answer
+ "" send a return (null text followed by usual return)
+ ogin: ppp word: whitewater log in.
+ /dev/cua1 specify the callout serial port cua1
+ 38400 specify baud rate
+ -detach normally, pppd forks and puts itself in the background;
+ this option prevents this
+ debug log status in syslog
+ crtscts use hardware flow control between computer and modem
+ (at 38400 this is a must)
+ modem indicate that this is a modem device; pppd will hang up the
+ phone before and after making the call
+ defaultroute once the PPP link is established, make it the
+ default route; if you have a PPP link to the Internet this
+ is probably what you want
+ 192.1.1.17: this is a degenerate case of a general option
+ of the form x.x.x.x:y.y.y.y . Here x.x.x.x is the local IP
+ address and y.y.y.y is the IP address of the remote end of the
+ PPP connection. If this option is not specified, or if just
+ one side is specified, then x.x.x.x defaults to the IP address
+ associated with the local machine's hostname (in /etc/hosts),
+ and y.y.y.y is determined by the remote machine. So if this
+ example had been taken from the fictional machine 'billpc',
+ this option would actually be redundant.
+
+pppd will write error messages and debugging logs to the syslogd
+daemon using the facility name "daemon". (Verbose output from chat
+uses facility "local2".) These messages may already be logged to the
+console or to a file like /usr/adm/messages; consult your
+/etc/syslog.conf file to see. If you want to make all pppd and chat
+messages go to the console, add the line
+ daemon,local2.* /dev/console
+to syslog.conf; make sure to put one or more TAB characters between
+the two fields.
+
+Example 2: Connecting to PPP server over hard-wired link.
+
+This is a slightly more complicated example. This is the script I run
+to make my own PPP link, which is over a hard-wired Gandalf link to an
+Ultrix machine running Morningstar PPP.
+
+ pppd connect /etc/ppp/ppp-connect defaultroute noipdefault debug \
+ kdebug 2 /dev/cua0 9600
+
+Here /etc/ppp/ppp-connect is the following script:
+ #! /bin/sh
+ /etc/ppp/sendbreak
+ chat -v -t60 "" \; "service :" blackice ogin: callahan word: PASSWORD \
+ black% "stty -echo; ppp" "Starting PPP now" && sleep 5
+
+This sends a break to wake up my terminal server, sends a semicolon
+(which lets my terminal server do autobaud detection), then says we
+want the service "blackice". It logs in, waits for a shell prompt
+("black%"), then starts PPP. The -t60 argument sets the timeout to a
+minute, since things here are sometimes very slow. (Ideally the
+expect-send strings for chat should be in a file.)
+
+The "&& sleep 5" causes the script to pause for 5 seconds, unless chat
+fails in which case it exits immediately. This is just to give the
+PPP server time to start (it's very slow). Also, the "stty -echo"
+turned out to be very important for me; without it, my pppd would
+sometimes start to send negotiation packets before the remote PPP
+server had time to turn off echoing. The negotiation packets would
+then get sent back to my local machine, be rejected (PPP is able to
+detect loopback) and pppd would fail before the remote PPP server even
+got going. The "stty -echo" command prevents this confusion. This
+kind of problem should only ever affect a *very* few people who
+connect to a PPP server that runs as a command on a slow Unix machine,
+but I wanted to mention it because it took me several frustrating
+hours to figure out.
+
+The pppd options are mostly familiar. Two that are new are
+"noipdefault" and "kdebug 2". "noipdefault" tells pppd to ask the
+remote end for the IP address to use; this is necessary if the PPP
+server implements dynamic IP address assignment as mine does (i.e., I
+don't know what address I'll get ahead of time). "kdebug 2" sets the
+kernel debugging level to 2, enabling slightly chattier messages from
+the ppp kernel code.
+
+
+
+Anyway, assuming your connection is working, you should see chat dial
+the modem, then perhaps some messages from pppd (depending on your
+syslog.conf setup), then some kernel messages like this:
+
+ ppp: channel ppp0 mtu changed to 1500
+ ppp: channel ppp0 open
+ ppp: channel ppp0 going up for IP packets!
+
+(These messages will only appear if you gave the option "kdebug 2" and
+have kern.info messages directed to the screen.) Simultaneously, pppd
+is also writing interesting things to /usr/adm/messages (or other log
+file, depending on syslog.conf).
+
+IF IT WORKS
+
+If you think you've got a connection, there are a number of things you
+can do to test it.
+
+First, type
+ /sbin/ifconfig
+(ifconfig may live elsewhere, depending on your distribution.) This
+should show you all the network interfaces that are 'UP'. ppp0 should
+be one of them, and you should recognize the first IP address as your
+own and the "POINT-TO-POINT ADDR" as the address of your server.
+Here's what it looks like on my machine:
+
+lo Link encap Local Loopback
+ inet addr 127.0.0.1 Bcast 127.255.255.255 Mask 255.0.0.0
+ UP LOOPBACK RUNNING MTU 2000 Metric 1
+ RX packets 0 errors 0 dropped 0 overrun 0
+ TX packets 0 errors 0 dropped 0 overrun 0
+
+ppp0 Link encap Serial Line IP
+ inet addr 192.76.32.2 P-t-P 129.67.1.165 Mask 255.255.255.0
+ UP POINTOPOINT RUNNING MTU 1500 Metric 1
+ RX packets 33 errors 0 dropped 0 overrun 0
+ TX packets 42 errors 0 dropped 0 overrun 0
+
+Now, type
+ ping z.z.z.z
+where z.z.z.z is the address of your server. This should work.
+Here's what it looks like for me:
+ waddington:~$ ping 129.67.1.165
+ PING 129.67.1.165 (129.67.1.165): 56 data bytes
+ 64 bytes from 129.67.1.165: icmp_seq=0 ttl=255 time=268 ms
+ 64 bytes from 129.67.1.165: icmp_seq=1 ttl=255 time=247 ms
+ 64 bytes from 129.67.1.165: icmp_seq=2 ttl=255 time=266 ms
+ ^C
+ --- 129.67.1.165 ping statistics ---
+ 3 packets transmitted, 3 packets received, 0% packet loss
+ round-trip min/avg/max = 247/260/268 ms
+ waddington:~$
+
+Try typing:
+ netstat -nr
+This should show three routes, something like this:
+Kernel routing table
+Destination Gateway Genmask Flags Metric Ref Use Iface
+129.67.1.165 0.0.0.0 255.255.255.255 UH 0 0 6 ppp0
+127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
+0.0.0.0 129.67.1.165 0.0.0.0 UG 0 0 6298 ppp0
+
+If your output looks similar but doesn't have the destination 0.0.0.0
+line (which refers to the default route used for connections), you may
+have run pppd without the 'defaultroute' option.
+
+At this point you can try telnetting/ftping/fingering whereever you
+want, bearing in mind that you'll have to use numeric IP addresses
+unless you've set up your /etc/resolv.conf correctly.
+
+IF IT DOESN'T WORK
+
+If you don't seem to get a connection, the thing to do is to collect
+'debug' output from pppd. To do this, make sure you run pppd with the
+'debug' option, and put the following two lines in your
+/etc/syslog.conf file:
+ daemon,local2.* /dev/console
+ daemon,local2.* /usr/adm/ppplog
+This will cause pppd's messages to be written to the current virtual
+console and to the file /usr/adm/ppplog. Note that the left-hand
+field and the right-hand field must be separated by at least one TAB
+character. After modifying /etc/syslog.conf, you must execute the
+command 'kill -HUP <pid>' where <pid> is the process ID of the
+currently running syslogd process to cause it to re-read the
+configuration file.
+
+Some messages to look for:
+ - "pppd[NNN]: Connected..." means that the "connect" script has
+ completed successfully.
+ - "pppd[NNN]: sent [LCP ConfReq"... means that pppd has attempted to
+ begin negotiation with the remote end.
+ - "pppd[NNN]: recv [LCP ConfReq"... means that pppd has received a
+ negotiation frame from the remote end.
+ - "pppd[NNN]: ipcp up" means that pppd has reached the point where
+ it believes the link is ready for IP traffic to travel across it.
+
+If you never see a "recv" message then there may be serious problems
+with your link. (For example, the link may not be passing all 8
+bits.) If that's the case, it would be useful to collect a debug log
+which contains all the bytes being passed between your computer and
+the remote PPP server. To do this, alter your syslog.conf lines to
+look like this
+ local2.*,kern.* /dev/console
+ local2.*,kern.* /usr/adm/ppplog
+and HUP the syslog daemon as before. Then, run pppd with the option
+"kdebug 5". Whatever characters arrive over the PPP terminal line
+will appear in the debugging output.
+
+Occasionally you may see a message like
+ ppp_toss: tossing frame, reason = 4
+The PPP code is throwing away a packet ("frame") from the remote
+server because of a serial overrun. This means your CPU isn't able to
+read characters from the serial port as quickly as they arrive; the
+best solution is to get a 16550A serial chip, which gives the CPU some
+grace period. Reasons other than 4 indicate other kinds of serial
+errors, which should not occur.
+
+During the initial connection sequence, you may see one or more
+messages which indicate "bad fcs". This refers to a checksum error in
+a received PPP frame, and usually occurs at the start of a session
+when the peer system is sending some "text" messages, such as "hello
+this is the XYZ company". Messages of "bad fcs" once the link is
+established and the routes have been added are not normal and indicate
+transmssion errors or noise on the telephone line.
+
+IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
+
+If you're still having difficulty, send the linux-activists PPP
+channel a bug report. It is extremely important to include as much
+information as possible; for example:
+ - the version number of the kernel you are using
+ - the version number of Linux PPP you are using
+ - the exact command you use to start the PPP session
+ - log output from a session run with the 'debug' option, captured
+ using local2.*,kern.* in your syslog.conf file
+ - the type of PPP peer that you are connecting to (eg, Xyzzy Corp
+ terminal server, Morningstar PPP software, etc)
+ - the kind of connection you use (modem, hardwired, etc...)
+
+DYNAMIC ADDRESS ASSIGNMENT
+
+You can use Linux PPP with a PPP server which assigns a different IP
+address every time you connect. You need to use the 'noipdefault'
+option to tell pppd to request the IP address from the remote host.
+
+Sometimes you may get an error message like "Cannot assign requested
+address" when you use a Linux client (for example, "talk"). This
+happens when the IP address given in /etc/hosts for our hostname
+differs from the IP address used by the PPP interface. The solution
+is to use ifconfig ppp0 to get the interface address and then edit
+/etc/hosts appropriately.
+
+SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
+
+Suppose you want to permit another machine to call yours up and start
+a PPP session. This is possible using Linux PPP.
+
+One way is to create an account named, say, 'ppp', with the login
+shell being a short script that starts pppd. For example, the passwd
+entry might look like this:
+ ppp:(encrypted password):102:50:PPP client login:/tmp:/etc/ppp/ppplogin
+Here the file /etc/ppp/ppplogin would be an executable script
+containing something like:
+ #!/bin/sh
+ exec /usr/etc/pppd passive :192.1.2.23
+Here we will insist that the remote machine use IP address 192.1.2.23,
+while the local PPP interface will use the IP address associated with
+this machine's hostname in /etc/hosts. The 'passive' option (which is
+not required) just means that pppd will try to open negotiations when
+it starts, but if it receives no reply it will just wait silently.
+This is appropriate if the remote end might take some time before it's
+ready to negotiate. (Note that the meaning of the 'passive' option
+changed between ppp-1.3 and ppp-2.0.)
+
+This setup is sufficient if you just want to connect two machines so
+that they can talk to one another. If you want to use Linux PPP to
+connect a single machine to an entire network, or to connect two
+networks together, then you need to arrange for packets to be routed
+from the networks to the PPP link. Setting up a link between networks
+is beyond the scope of this document; you should examine the routing
+options in the manual page for pppd carefully and find out about
+routed, etc.
+
+Let's consider just the first case. Suppose you have a Linux machine
+attached to an Ethernet, and you want to allow its PPP peer to be able
+to communicate with hosts on that Ethernet. To do this, you should
+have the remote machine use an IP address that would normally appear
+to be on the local Ethernet segment and you should give the 'proxyarp'
+option to pppd on the server. Suppose, for example, we have this
+setup:
+
+ 192.1.2.23 192.1.2.17
++-----------+ PPP link +----------+
+| chelseapc | ------------------- | billpc |
++-----------+ +----------+
+ | Ethernet
+ ----------------------------------- 192.1.2.x
+
+Here the PPP and Ethernet interfaces of billpc will have IP address
+192.1.2.17. (It's OK for one or more PPP interfaces on a machine to
+share an IP address with an Ethernet interface.) There is an
+appropriate entry in /etc/passwd on billpc to allow chelseapc to call
+in, with the /etc/ppp/ppplogin script containing
+ #!/bin/sh
+ exec /usr/etc/pppd passive proxyarp :192.1.2.23
+When the link comes up, pppd will enter a "proxy arp" entry for
+chelseapc into the arp table on billpc. What this means effectively
+is that billpc will pretend to the other machines on the 192.1.2.x
+Ethernet that its Ethernet interface is ALSO the interface for
+chelseapc (192.1.2.23) as well as billpc (192.1.2.17). In practice
+this means that chelseapc can communicate just as if it was directly
+connected to the Ethernet.
+
+ADDING MORE PPP CHANNELS
+
+By default, Linux PPP comes with 4 kernel channels, which means that
+at most 4 simultaneous PPP sessions are possible. If you desire more
+such sessions (for example if you are serving many dialup lines), you
+can easily reconfigure the kernel to add new channels. There are two
+steps.
+
+First you need to edit the kernel file drivers/net/Space.c . As
+distributed, it contains a section that looks like this:
+
+#if defined(CONFIG_PPP)
+extern int ppp_init(struct device *);
+static struct device ppp3_dev = {
+ "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, NEXT_DEV, ppp_init, };
+static struct device ppp2_dev = {
+ "ppp2", 0x0, 0x0, 0x0, 0x0, 2, 0, 0, 0, 0, &ppp3_dev, ppp_init, };
+static struct device ppp1_dev = {
+ "ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &ppp2_dev, ppp_init, };
+static struct device ppp0_dev = {
+ "ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &ppp1_dev, ppp_init, };
+#undef NEXT_DEV
+#define NEXT_DEV (&ppp0_dev)
+#endif /* PPP */
+
+The pattern should be obvious. For more channels, you need to add
+more "static struct device pppN_dev" lines, changing the first, sixth
+and eleventh structure entries as appropriate. The highest numbered
+PPP device should have NEXT_DEV in its eleventh structure field, and
+you should change the ppp3_dev structure to have &ppp4_dev there
+instead.
+
+For example, to add 2 extra channels, you would have
+
+#if defined(CONFIG_PPP)
+extern int ppp_init(struct device *);
+static struct device ppp5_dev = {
+ "ppp5", 0x0, 0x0, 0x0, 0x0, 5, 0, 0, 0, 0, NEXT_DEV, ppp_init, };
+static struct device ppp4_dev = {
+ "ppp4", 0x0, 0x0, 0x0, 0x0, 4, 0, 0, 0, 0, &ppp5_dev, ppp_init, };
+static struct device ppp3_dev = {
+ "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &ppp4_dev, ppp_init, };
+... etc.
+
+Second, you need to change the line in ppp.h (in include/linux) to
+change the line that reads
+
+#define PPP_NRUNIT 4
+
+to show the new number of channels; in our case it would become
+
+#define PPP_NRUNIT 6
+
+Finally, recompile and reboot. The bootup message and the contents of
+/proc/net/dev should show the correct number of channels.
+
+CHANGES FROM LINUX PPP 0.1.x
+
+Linux PPP 0.1.x was based on the free PPP package PPP-1.3. Linux PPP
+0.2.1 is based on PPP-2.0.4. There have been some changes to the pppd
+options along with significant enhancements. You should read
+"RELNOTES" in the pppd directory for a description of the changes.
+
+Also, some options which were added to PPP-1.3 for the Linux version
+have now changed names:
+ 'defroute' is now 'defaultroute'
+ 'kerndebug' is now 'kdebug'
+ 'dropdtr' is now 'modem'
+In addition, it is now necessary to use the 'noipdefault' option if
+you want to get the local IP address from the remote PPP server.
+
+CONCLUSION
+
+Good luck!
+
+Michael
--- /dev/null
+
+This file (README.osf) contains instructions for installing ppp-2.2 on a
+DEC Alpha running OSF/1 version 2.0 or 3.0. The original STREAMS
+module code is by (and copyrighted by) Brad Clements. See the source
+files and the general README file for full credits and copyright notices.
+
+If you would like to be on a mailing list concerning the ppp package,
+send mail to srt@cs.unt.edu and let me know. This mailing list should
+not have any regular traffic --- I will use it only if bugs are reported
+to notify everyone of bug-fixes.
+
+Note for users of the ppp-2.1.2 package: I have included a fix
+for the non-STREAMS tty drivers in this release. If you were using
+version 2.1.2 with a hardware serial port, then you probably used the
+"rlogin-kludge" that I described in the README that came with 2.1.2.
+You don't need this any more, and will have a more efficient connection
+if you get rid of this old work-around.
+
+Below are the steps for installing PPP on a DEC AXP system running OSF/1.
+You must do all of the following as "root".
+
+1. Make the kernel sources, daemon, chat, and pppstat program by typing
+
+ ./configure
+ make install
+
+ in the directory that this file unpacked into. This installs the
+ binaries for the PPP daemon and the statistics program in
+ /usr/local/etc/ppp. If you want them somewhere else, just change
+ the definition of BINDIR in the top level Makefile.osf.
+
+2. This step differs depending on whether you are running OSF/1 V3.0
+ or later.
+
+ FOR OSF/1 VERSIONS PRIOR TO V3.0:
+
+ | Add the following lines to the file /sys/conf/files:
+ |
+ | streamsm/ppp_if.c optional ppp Notbinary
+ | streamsm/ppp_async.c optional ppp Notbinary
+ | streamsm/ppp_init.c optional ppp Notbinary
+ | streamsm/vjcompress.c optional ppp Notbinary
+ | streamsm/bsd-comp.c optional ppp Notbinary
+ | streamsm/ppp_comp.c optional ppp Notbinary
+ |
+ |
+ | Edit the file /sys/streams/str_config.c --- at the end there will be a
+ | comment to the effect of "add new configurations above this comment".
+ | Add the following lines above this comment:
+ |
+ | bzero((caddr_t)&sb, sizeof(sb));
+ | sb.sc_version = OSF_STREAMS_CONFIG_10;
+ |
+ | retval = ppp_configure(SYSCONFIG_CONFIGURE,
+ | &sb, sc_size, &sc, sc_size);
+
+ FOR OSF/1 VERSIONS V3.0 AND LATER:
+
+ | Add the following lines to the file /sys/conf/files:
+ |
+ | streamsm/ppp_if.c optional ppp if_dynamic ppp Notbinary
+ | streamsm/ppp_async.c optional ppp if_dynamic ppp Notbinary
+ | streamsm/ppp_init.c optional ppp if_dynamic ppp Notbinary
+ | streamsm/vjcompress.c optional ppp if_dynamic ppp Notbinary
+ | streamsm/bsd-comp.c optional ppp if_dynamic ppp Notbinary
+ | streamsm/ppp_comp.c optional ppp if_dynamic ppp Notbinary
+
+4. Find your system's configuration file. This should be called
+ /sys/conf/SYSNAME, where SYSNAME is replaced by the name of your
+ host. For example, on my machine (zaphod.csci.unt.edu) it it called
+ /sys/conf/ZAPHOD. I will refer to this file from now on as
+ /sys/conf/SYSNAME.
+
+5. Add the following line at the end of /sys/conf/SYSNAME:
+
+ pseudo-device ppp 2
+
+6. Build a new kernel by using the command
+
+ doconfig -c SYSNAME
+
+ (say "n" to "Do you want to edit...").
+
+7. Copy the new kernel to /vmunix --- I'm usually pretty nervous about
+ writing over a perfectly good kernel with one that I'm not sure
+ about, so I will usually "mv /vmunix /vmunix.old" first. To put
+ the new kernel in place, do a "cp /sys/SYSNAME/vmunix /vmunix".
+
+8. Make sure your system is set up so that it can act like a gateway
+ for messages to your new connection. In particular, check the file
+ /etc/rc.config for the line define ROUTER, and make sure it is
+ defined as "yes".
+
+9. Reboot and you're ready to go!
+
+Hopefully, that should work with no hitches. If there are problems, or
+if I have made a mistake in these instructions, please let me know.
+
+Steve Tate
+University of North Texas
+srt@cs.unt.edu
+
--- /dev/null
+This file describes the installation process for ppp-2.2 on systems
+running SunOS 4.x (or the equivalent). This package does not
+currently work under Solaris 2.
+
+The STREAMS modules in the sunos directory provide kernel support for
+PPP on SunOS 4.x systems. They have been tested under SunOS 4.1.3 on
+a SparcStation 10. They should work under earlier SunOS 4.x systems,
+but no guarantees are given.
+
+The easiest way to install these modules is to load them into the
+running kernel using the `modload' command. They can alternatively be
+linked into the kernel image, but this requires rebuilding the kernel.
+
+
+Installation.
+*************
+
+1. Run the configure script and make the user-level programs and the
+kernel modules.
+
+ ./configure
+ make
+
+2. Install the pppd and chat programs (you need to be root to do this):
+
+ make install
+
+3. Load the ppp module (you need to be root for this too). In the
+sunos directory, do:
+
+ /usr/etc/modload ppp_driver.o
+
+You will want to do this "modloading" in your /etc/rc.local file
+once you have everything installed. The ppp module is copied to
+/usr/local/etc by default, so you can put something like the following
+in /etc/rc.local:
+
+ if [ -f /usr/local/etc/ppp_driver.o ]; then
+ /usr/etc/modload /usr/local/etc/ppp_driver.o
+ fi
+
+On some systems, /usr/local/etc is mounted read-only. On such
+systems, add `-o /etc/ppp/ppp_driver' to the modload command line.
+
+NOTE: pppstats now works differently, so there is no need to use the
+-sym flag to modload, as required with earlier versions.
--- /dev/null
+
+Installing PPP on an Ultrix system requires rebuilding the kernel and
+rebooting, in addition to making and installing the pppd and chat
+programs. These instructions apply to RISC (MIPS) systems. This
+software has been tested under Ultrix 4.4; it should also work under
+Ultrix 4.2 or 4.3.
+
+
+Kernel installation procedure.
+******************************
+
+If you have not previously had an earlier version of this package
+installed in the kernel, follow these steps:
+
+1. Become root.
+
+2. Apply the patches in the file ultrix/patches using the command:
+
+ patch -p <ultrix/patches
+
+This will edit the following files, saving the original versions in a
+file with `.orig' appended to the name:
+
+ /usr/sys/h/ioctl.h
+ /usr/sys/net/net/if.h
+ /usr/sys/net/net/netisr.h
+ /usr/sys/net/net/conf_net.c
+ /usr/sys/data/pseudo_data.c
+ /usr/sys/data/tty_conf_data.c
+ /usr/sys/conf/mips/files.mips
+
+Alternatively, edit these files according to the differences shown in
+ultrix/patches.
+
+3. Copy the following files to /sys/io/netif:
+
+ net/if_ppp.h
+ net/ppp-comp.h
+ net/ppp_defs.h
+ net/slcompress.h
+ ultrix/bsd-comp.c
+ ultrix/if_ppp.c
+ ultrix/if_pppvar.h
+ ultrix/ppp_tty.c
+ ultrix/slcompress.c
+
+4. Add a line like this to the configuration file for your kernel:
+
+ pseudo-device ppp 2
+
+The `2' indicates the number of interfaces desired. The configuration
+file should be in /usr/sys/conf/mips.
+
+5. Rebuild your kernel. The simplest way to do this is with the
+`doconfig' command, like this:
+
+ /etc/doconfig -c kernel-name
+
+where `kernel-name' should be replaced by the name of your kernel
+configuration file. Alternatively, run config, cd to the compilation
+directory, and run make.
+
+6. Copy the new /vmunix to /. It would be a good idea to keep a copy
+of your old /vmunix in / under a different name.
+
+7. Reboot the system.
+
+
+If you have ppp-2.1.2 or earlier already installed in your kernel,
+some files will already have been modified as required. The files
+which still need to be modified are:
+
+ /usr/sys/net/net/netisr.h
+ /usr/sys/net/net/conf_net.c
+ /usr/sys/conf/mips/files.mips
+
+The file ultrix/upgrade is a patch file to modify these files. The
+upgrade procedure is much the same as the installation procedure
+described above, except that you use ultrix/upgrade in step 2 instead
+of ultrix/patches, and step 4 should already have been done.
+
+Earlier versions of ppp-2.x replaced if.o with a modified version.
+This version does not need the modifications, so you can use either
+the original or the modified version.
+
+
+Installing pppd and chat.
+*************************
+
+1. cd to the ppp-2.2 directory and do:
+
+ ./configure
+ make
+
+2. Become root, and do:
+
+ make install
+
+
+Credits.
+********
+
+The original port to Ultrix was done by:
+
+ Per Sundstrom
+ DEC, Sweden
+ email: sundstrom@stkhlm.enet.dec.com
+
+and
+
+ Robert Olsson
+ Swedish University of Agricultural Sciences
+ and also RO Komm. & Konsult
+ email: robert@robur.slu.se
+
+It was updated to ppp-2.2 by
+
+ Paul Mackerras
+ Dept. of Computer Science
+ Australian National University
+ paulus@cs.anu.edu.au
+
+(with some assistance from Per Sundstrom).
--- /dev/null
+ Setting up a PPP link.
+
+Setting up a PPP link between two machines involves several steps:
+
+1. Prepare both of the machines which are to be connected:
+ 1A. Make and install the pppd, pppstats and chat programs.
+ 1B. Install the ppp driver in the kernel.
+The README.* files give details on this step.
+
+2. Decide on the IP addresses to be used and the level of
+authentication required by each machine, and set up the /etc/ppp
+directories accordingly.
+
+3. Set up the serial link between the two machines and run pppd on
+each machine. The two pppd's then negotiate and set up the link.
+
+Step 1 is described in the system-specific README.* files. The
+remaining steps are described below. Steps 1 and 2 need only be done
+once; step 3 is done each time the link is to be established.
+
+
+Choosing IP addresses.
+
+If a host is already connected to the Internet via a LAN such as
+Ethernet, then it will already have at least one IP address assigned,
+which will usually be the IP address of the LAN interface. In such
+cases, it is usually most convenient to use that address as the local
+IP address of the PPP interface(s) on that host. This is OK because
+the PPP interface(s) are point-to-point interfaces.
+
+If a host is not connected to the Internet, then an IP address needs
+to be assigned for it. If PPP is to be used to link it to another
+host which is connected to the Internet, is is usually most convenient
+to assign it an address on the same subnet as the remote host. If the
+other host is not connected to the Internet either, then the choice of
+IP addresses is quite arbitrary.
+
+Authentication.
+
+The level of authentication required depends on the situation, but
+generally hosts which are connected to the Internet via a LAN should
+be set up to (a) require the remote host to authenticate itself, and
+(b) restrict the remote host's choice of IP address, based on its
+identity. Otherwise the possibility exists for a remote host to
+impersonate another host on the local subnet. (However, when you are
+first installing PPP, it is probably easier to leave authentication
+disabled until you get to the point where you can successfully
+establish a link.)
+
+Setting up /etc/ppp.
+
+The /etc/ppp directory contains various files used by pppd; it should
+be created by the system administrator when installing PPP. It would
+typically contain the following files:
+
+ chap-secrets Secrets used for authenticating with CHAP
+ pap-secrets Secrets used for authenticating with PAP
+ options Options that the system administrator wants to
+ apply whenever pppd is run
+
+Since this directory contains files of secrets used for
+authentication, it should not be in a partition which is accessible
+from other hosts (e.g., exported by NFS).
+
+The `options' file contains any options which the system administrator
+wants pppd to use whenever it is run. If authentication is to be
+required, this should contain the `auth' and `usehostname' options.
+If the /etc/ppp/options file does not exist, or is not readable by
+pppd, it will refuse to run.
+
+Secrets for PAP (Password Authentication Protocol) authentication are
+stored in /etc/ppp/pap-secrets; secrets for CHAP (Cryptographic
+Authentication Protocol) are stored in /etc/ppp/chap-secrets. These
+files have the same format, and store secrets both for authenticating
+other hosts, and for authenticating this host to others. The format
+is that there are 3 or more words per line, which are:
+
+ client - name of the machine to be authenticated
+ server - name of the machine requiring the authentication
+ secret - password or CHAP secret known by both client and server
+ IP addresses - zero or more IP addresses which the client may
+ use (this field is only used on the server).
+
+For example, if a LAN-connected host called "worksun" is to require
+authentication, and a host "bsdbox" is to connect to it and
+authenticate itself using CHAP, then both machines should have a
+/etc/ppp/chap-secrets file, which should contain a line something
+like:
+
+ bsdbox worksun "an unguessable secret" bsdbox.my.domain
+
+Setting up syslog.
+
+pppd issues messages using syslog facility daemon (or local2 if it has
+been compiled with debugging enabled); chat uses facility local2. It
+is useful to see messages of priority notice or higher on the console.
+To see these, 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:
+
+*.err;kern.debug;daemon,local2,auth.notice;mail.crit /dev/console
+
+If you want to see more messages from pppd, request messages of
+priority info or higher for facility daemon, like this:
+
+*.err;kern.debug;daemon.info;local2,auth.notice;mail.crit /dev/console
+
+It is also useful to add a line like this:
+
+daemon,local2.debug /etc/ppp/ppp-log
+
+If you do this, you will need to create an empty /etc/ppp/ppp-log
+file.
+
+After modifying syslog.conf, you will then need to send a HUP signal
+to syslogd (or reboot).
+
+
+Setting up a PPP link.
+
+Establishing a PPP connection between two machines basically involves
+setting up a serial link and running pppd on both ends of the link.
+How this is done depends on the nature of the serial link, which may
+be as simple as a null modem cable between two machines, or it may
+involve modems, terminal servers, telnet sessions, etc. The `chat'
+program is very useful in setting up the serial link because it
+enables you to automate any dialog which may be required, e.g.,
+logging in to the remote machine with a username and password, issuing
+a command to start ppp on the remote machine, etc. As an example,
+the link could be started by issuing a command like
+
+ pppd /dev/ttya 38400 connect 'chat -f /etc/ppp/chat-script'
+
+where the file /etc/ppp/chat-script contains
+
+ "" atdt2135476
+ login: myname
+ Password: "\qmypassword"
+ "$ " "\qpppd"
+
+The words in this script are alternately strings to look for and
+strings to send. In this example, we start by sending a dial command
+to the modem; then we look for "login:", send "myname", look for
+"Password:", send "mypassword" (the "\q" prevents chat from logging it
+when you use the -v option), look for "$ " (the end of the shell
+prompt) and send "pppd" to start up ppp on the remote machine (the
+"\q" cancels the effect of the previous "\q").
+
+In another scenario, you could establish the serial link manually,
+e.g. using Kermit to dial out, log into the remote machine, and issue
+the commands to start ppp there. Then you have to exit Kermit without
+having the modem hang up, and then start pppd locally, using a command
+like this:
+
+ pppd /dev/ttya 38400
+
+When a device is given, as in this command line, pppd will put itself
+in the background. The two pppd's should then negotiate and bring up
+the link. If you have edited /etc/syslog.conf as described above, you
+will see messages from pppd giving the local and remote IP addresses
+of the link when it is successfully established.
+
+If the local machine has no other connection to the Internet, you can
+ask pppd to add a default route via the remote host by adding the
+`defaultroute' option to the pppd command.
+
+N.B. When you run pppd on the remote machine, you usually want it to
+use the tty device where you logged in. In this case, do not give a
+device name to pppd; it uses the controlling tty by default. This may
+be a pty, e.g., if the serial link contains a telnet session, except
+under Ultrix (pppd will not run on a pty under Ultrix, due to the pty
+driver not passing ioctls to the ppp line discipline code).
+
+If the remote machine is connected to the Internet via a LAN, it is
+often useful to add the `proxyarp' option. The `asyncmap' option is
+also useful if the serial line is not completely transparent;
+`asyncmap 200a0000' is appropriate if the serial link includes a
+telnet.
+
+Some people find it convenient to set up a `ppp' username on the
+remote machine, with no password, and a shell script which runs pppd
+as its login shell.
+
+Other random points about running pppd:
+ - If you want the local address of the PPP link to be
+ different from the (first) IP address of the host, you need
+ to put the desired address on the pppd command line with a
+ colon appended.
+ - The performance will probably be better if you reduce the
+ MRU (maximum receive unit) on both ends; 296 is a good
+ value. To do this, use the option `mru 296'.
+ - You DO NOT need to use ifconfig to configure the addresses
+ of the ppp interface. Pppd does all the necessary work
+ (assigning addresses, marking the interface up, etc.).
+
+
+Terminating the PPP link.
+
+When you wish terminate the PPP link, you should send a TERM or INTR
+signal to one of the pppd's, e.g., with a command like:
+
+ kill `cat /etc/ppp/ppp0.pid`
+
+on SunOS or Ultrix, or
+
+ kill `cat /var/run/ppp0.pid`
+
+on {386,Net,Free}BSD.
+
+That pppd will inform the other pppd to terminate, and they will both
+clean up and exit.
+
+If pppd is attached to a hardware serial port connected to a modem,
+then it should get a HUP signal when the modem hangs up, which will
+cause it to clean up and exit. Whether it does or not depends on the
+driver, and on Suns, on the setting of the `tty soft carrier' flag,
+which is manipulated by the /usr/etc/ttysoftcar program (see
+ttysoftcar(8)).
+
+
+Debugging.
+
+If the link comes up successfully, you should see messages logged to
+the console like "Local IP address: xx.xx.xx.xx" and "Remote IP
+address: yy.yy.yy.yy" (assuming you've edited /etc/syslog.conf as
+described above). If the link doesn't come up, it could be due to any
+of several factors:
+
+- Perhaps the serial connection is not being set up successfully, or
+you haven't succeeded in getting ppp running on the remote machine.
+You can use the -v flag to chat; it will then log the characters it
+sends and receives (using syslog with facility `local2' and level
+`debug').
+
+- Perhaps the PPP negotiation with the peer is failing. You can use
+the `debug' option to pppd; it will then log the contents of all
+control packets sent and received (using syslog with facility `daemon'
+and level `debug').
+
+In some cases, the link will come up successfully, but you may then be
+unable to use network-based applications over the link. This usually
+indicates an IP-address assignment problem or a routing problem. Or
+you may be able to communicate with the peer machine but not any
+machine beyond that. Typically this is a routing problem. For the
+common case where the local machine is only connected to the Internet
+via the peer, this problem can usually be solved if you:
+ - assign the local machine an IP address on the same subnet
+ as the remote machine
+ - use the `defaultroute' option on the local pppd
+ - use the `proxyarp' option on the remote pppd.
+
+For solving routing and network problems, the ifconfig, netstat -i,
+netstat -r, ping and traceroute commands are useful.
--- /dev/null
+* Things to do *
+
+1. Support dial-on-demand in PPP
+
+2. Implement link quality monitoring
+
+3. Implement other network control protocols
--- /dev/null
+
+strload -m ppp_async
+strload -m ppp_if
+strload -m ppp_comp
--- /dev/null
+ppp_async_load
--- /dev/null
+#
+# ppp top level makefile for *bsd systems
+#
+
+BINDIR?= /usr/sbin
+
+SUBDIR= chat pppd pppstats
+MAKE+= BINDIR=$(BINDIR)
+
+kernel:
+ @sh -e freebsd-2.0/kinstall.sh
+
+.include <bsd.subdir.mk>
--- /dev/null
+*** files.orig Wed Dec 14 13:11:12 1994
+--- files Wed Dec 14 13:13:56 1994
+***************
+*** 139,144 ****
+--- 139,146 ----
+ net/if_ethersubr.c optional ether
+ net/if_loop.c optional loop
+ net/if_ppp.c optional ppp
++ net/ppp_tty.c optional ppp
++ net/bsd-comp.c optional ppp
+ net/if_sl.c optional sl
+ net/pppcompress.c optional ppp
+ net/radix.c standard
--- /dev/null
+# PPP top-level Makefile for Linux.
+
+all:
+ cd chat; $(MAKE) all
+ cd pppd; $(MAKE) all
+
+install:
+ cd chat; $(MAKE) install
+ cd pppd; $(MAKE) install
+
+clean:
+ cd chat; $(MAKE) clean
+ cd pppd; $(MAKE) clean
--- /dev/null
+\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
+@author by Paul Mackerras
+@end titlepage
+
+@node Top, Introduction, (dir), (dir)
+
+@ifinfo
+This file documents the ppp-2.x package for setting up network links
+over serial lines using the Point-to-Point Protocol.
+
+@end ifinfo
+
+@menu
+* Introduction:: What PPP is and what you can use it for.
+* Installation:: How to compile and install the software.
+* Configuration:: How to set up your system for
+establishing a link to another system.
+* Security:: Potential dangers and how to avoid them.
+* Compression::
+@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.
+
+As an example, an otherwise isolated system could connect to another
+system via a modem using PPP. Suppose that the second system was
+connected to the Internet. When the PPP link is established, the first
+system is then also connected to the Internet. It can establish
+connections with any other Internet host. Users can then use
+a wide range of network-based applications on the first system, such as
+telnet, ftp, rlogin, email, Mosaic, sup, and X clients and servers.
+
+Features of PPP include:
+@itemize
+@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
+
+This 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 (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.
+
+@item
+The PPP daemon (@code{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.
+@end itemize
+
+@menu
+* PPP Concepts::
+@end menu
+
+@node PPP Concepts, , Introduction, Introduction
+@section PPP Concepts
+
+Establishing a PPP link involves communication between two systems. The
+two systems 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''. Although we may sometimes refer to one system as a ``client''
+and the other as a ``server'', this distinction is not made in the PPP
+protocols.
+
+PPP requires the use of a communications medium which transmits 8 bits
+per character. Typically this is a serial line, perhaps including
+modems and telephone lines, but other media can be used (even a telnet
+session). The medium must be full duplex---capable of transmitting
+characters independently in both directions. Note that PPP cannot work
+over a serial link which transmits only 7 bits per character.
+
+PPP has a mechanism to avoid sending certain characters if it is known
+that the medium 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 lines. For
+synchronous serial connections, the HDLC bit-stuffing procedure is used
+instead.
+
+During the lifetime of a PPP link, it proceeds through several phases:
+
+@enumerate
+@item
+Communications establishment. In this phase, the underlying
+communications medium is prepared for use. This may involve sending
+commands to a modem to cause it to dial the remote system. When the
+remote system answers, there may be a dialog involving a username and
+password. Or, in the case of two systems connected directly by a cable,
+there may be nothing to do.
+
+@item
+Link Control Protocol (LCP) negotiation. In this phase, the peers send
+LCP packets to each other to negotiate various parameters of the
+link, 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 (NP) 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 Network Control Protocol 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 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
+sit 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 underlying communications medium is
+interrupted, for example when the modem loses carrier and hangs up.
+
+@end enumerate
+
+PPP is defined in several RFC (Request For Comments) documents, 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).
+
+@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 SunOS 4.x, AIX 4.1, 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, Linux), 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.)
+
+@node Configuration, Security, Installation, Top
+@chapter Configuration
+
+@node Security, Compression, Configuration, Top
+@chapter Security
+
+@node Compression, , Security, Top
+@chapter Compression
+
+@bye
--- /dev/null
+name="ppp" parent="pseudo" instance=0;
--- /dev/null
+#
+# ppp top level makefile
+#
+
+BINDIR = /usr/local/etc
+MANDIR = /usr/local/man
+
+all:
+ cd chat; $(MAKE) all
+ cd pppd; $(MAKE) all
+ cd pppstats; $(MAKE) all
+
+install:
+ cd chat; $(MAKE) BINDIR=$(BINDIR) MANDIR=$(MANDIR) install
+ cd pppd; $(MAKE) BINDIR=$(BINDIR) MANDIR=$(MANDIR) install
+ cd pppstats; $(MAKE) BINDIR=$(BINDIR) MANDIR=$(MANDIR) install
+
+clean:
+ rm -f *~
+ cd chat; $(MAKE) clean
+ cd pppd; $(MAKE) clean
+ cd pppstats; $(MAKE) clean
+
--- /dev/null
+*** /usr/sys/h/ioctl.h.orig Fri Dec 9 10:05:18 1994
+--- /usr/sys/h/ioctl.h Fri Dec 9 10:06:06 1994
+***************
+*** 405,410 ****
+--- 405,411 ----
+ #define SLPDISC 0x07 /* BSD Serial Line IP */
+ #define PCMDISC 0x08 /* Peripheral Control Module
+ for dial and button boxex */
++ #define PPPDISC 0x09 /* PPP Point-to-Point Protocol */
+ /* Line disc #'s 16-23 are
+ reserved for local extension.*/
+
+*** /usr/sys/net/net/if.h.orig Wed Aug 4 01:57:00 1993
+--- /usr/sys/net/net/if.h Fri Dec 9 09:29:11 1994
+***************
+*** 231,236 ****
+--- 231,237 ----
+ #define IFT_XETHER 0x1a /* obsolete 3MB experimental ethernet */
+ #define IFT_NSIP 0x1b /* XNS over IP */
+ #define IFT_SLIP 0x1c /* IP over generic TTY */
++ #define IFT_PPP 0x1d /* PPP over generic TTY */
+
+ /*
+ * Output queues (ifp->if_snd) and internetwork datagram level (pup level 1)
+*** /usr/sys/net/net/netisr.h.orig Fri Dec 9 09:53:17 1994
+--- /usr/sys/net/net/netisr.h Fri Dec 9 09:54:14 1994
+***************
+*** 77,82 ****
+--- 77,83 ----
+ #define NETISR_LAT 14 /* same as AF_LAT */
+ #define NETISR_BSC 15 /* same as AF_BSC */
+ #define NETISR_DLO 19 /* same as AF_OSI */
++ #define NETISR_PPP 26 /* Point-to-Point Protocol */
+
+ #define schednetisr(anisr) { set_bit_atomic(anisr,&netisr); setsoftnet(); }
+
+*** /usr/sys/net/net/conf_net.c.orig Fri Dec 9 13:29:49 1994
+--- /usr/sys/net/net/conf_net.c Fri Dec 9 13:32:50 1994
+***************
+*** 84,89 ****
+--- 84,90 ----
+ #ifdef vax
+ #include "bsc.h"
+ #endif vax
++ #include "ppp.h"
+
+
+ #if ((NETHER==0 && NFDDI==0) || NINET==0)
+***************
+*** 251,257 ****
+ };
+
+
+! extern int rawintr(), ipintr(), nsintr(), dnetintr(), dlointr(), dliintr(), latintr(), bscintr();
+ #ifdef __mips
+ extern int scsiisr();
+ #endif
+--- 252,258 ----
+ };
+
+
+! extern int rawintr(), ipintr(), nsintr(), dnetintr(), dlointr(), dliintr(), latintr(), bscintr(), pppintr();
+ #ifdef __mips
+ extern int scsiisr();
+ #endif
+***************
+*** 289,294 ****
+--- 290,298 ----
+ {NETISR_SCSI,scsiisr},
+ #endif /* NSCSI > 0 || NSII > 0 || NASC > 0 */
+ #endif /* __mips */
++ #if NPPP > 0
++ {NETISR_PPP,pppintr},
++ #endif /* NPPP */
+
+ {-1 ,0}
+ };
+*** /usr/sys/data/pseudo_data.c.orig Sat Sep 19 06:20:31 1992
+--- /usr/sys/data/pseudo_data.c Fri Dec 9 09:32:23 1994
+***************
+*** 25,30 ****
+--- 25,35 ----
+
+ #endif /* NSL > 0 */
+
++ #include "ppp.h"
++ #if NPPP > 0
++ pppattach();
++ #endif
++
+ return;
+ }
+
+*** /usr/sys/data/tty_conf_data.c.orig Sat Sep 19 06:19:21 1992
+--- /usr/sys/data/tty_conf_data.c Fri Dec 9 09:32:38 1994
+***************
+*** 83,88 ****
+--- 83,94 ----
+ int slopen(), slclose(), slinput(), sltioctl(), slstart();
+ #endif
+
++ #include "ppp.h"
++ #if NPPP > 0
++ int pppopen(), pppclose(), pppread(), pppwrite(), pppinput();
++ int ppptioctl(), pppstart();
++ #endif
++
+ #ifdef BINARY
+
+ extern int nldisp;
+***************
+*** 141,146 ****
+--- 147,161 ----
+ nodev, nodev, nodev, nodev, nodev,
+ nodev, nodev, nodev, nodev, nodev,
+ #endif
++
++ #if NPPP > 0
++ pppopen, pppclose, pppread, pppwrite, ppptioctl,
++ pppinput, nodev, nulldev, pppstart, nulldev, /* 9 - PPPDISC */
++ #else
++ nodev, nodev, nodev, nodev, nodev,
++ nodev, nodev, nodev, nodev, nodev,
++ #endif
++
+
+ };
+
+*** /usr/sys/conf/mips/files.mips.orig Sat Sep 11 06:09:28 1993
+--- /usr/sys/conf/mips/files.mips Fri Dec 9 09:32:01 1994
+***************
+*** 114,120 ****
+ io/netif/if_ln_copy.s optional ln Binary
+ io/netif/if_ne.c optional ne device-driver Binary
+ io/netif/if_sl.c optional sl device-driver Binary Unsupported
+! io/netif/slcompress.c optional sl device-driver Binary Unsupported
+ io/netif/if_qe.c optional qe device-driver Binary
+ io/netif/if_uba.c optional inet device-driver Binary
+ io/netif/if_ni.c optional bvpni device-driver Binary
+--- 114,123 ----
+ io/netif/if_ln_copy.s optional ln Binary
+ io/netif/if_ne.c optional ne device-driver Binary
+ io/netif/if_sl.c optional sl device-driver Binary Unsupported
+! io/netif/if_ppp.c optional ppp device-driver Notbinary
+! io/netif/ppp_tty.c optional ppp device-driver Notbinary
+! io/netif/bsd-comp.c optional ppp device-driver Notbinary
+! io/netif/slcompress.c optional sl or ppp device-driver Notbinary
+ io/netif/if_qe.c optional qe device-driver Binary
+ io/netif/if_uba.c optional inet device-driver Binary
+ io/netif/if_ni.c optional bvpni device-driver Binary
--- /dev/null
+*** /usr/sys/net/net/netisr.h.orig Fri Dec 9 09:53:17 1994
+--- /usr/sys/net/net/netisr.h Fri Dec 9 09:54:14 1994
+***************
+*** 77,82 ****
+--- 77,83 ----
+ #define NETISR_LAT 14 /* same as AF_LAT */
+ #define NETISR_BSC 15 /* same as AF_BSC */
+ #define NETISR_DLO 19 /* same as AF_OSI */
++ #define NETISR_PPP 26 /* Point-to-Point Protocol */
+
+ #define schednetisr(anisr) { set_bit_atomic(anisr,&netisr); setsoftnet(); }
+
+*** /usr/sys/net/net/conf_net.c.orig Fri Dec 9 13:29:49 1994
+--- /usr/sys/net/net/conf_net.c Fri Dec 9 13:32:50 1994
+***************
+*** 84,89 ****
+--- 84,90 ----
+ #ifdef vax
+ #include "bsc.h"
+ #endif vax
++ #include "ppp.h"
+
+
+ #if ((NETHER==0 && NFDDI==0) || NINET==0)
+***************
+*** 251,257 ****
+ };
+
+
+! extern int rawintr(), ipintr(), nsintr(), dnetintr(), dlointr(), dliintr(), latintr(), bscintr();
+ #ifdef __mips
+ extern int scsiisr();
+ #endif
+--- 252,258 ----
+ };
+
+
+! extern int rawintr(), ipintr(), nsintr(), dnetintr(), dlointr(), dliintr(), latintr(), bscintr(), pppintr();
+ #ifdef __mips
+ extern int scsiisr();
+ #endif
+***************
+*** 289,294 ****
+--- 290,298 ----
+ {NETISR_SCSI,scsiisr},
+ #endif /* NSCSI > 0 || NSII > 0 || NASC > 0 */
+ #endif /* __mips */
++ #if NPPP > 0
++ {NETISR_PPP,pppintr},
++ #endif /* NPPP */
+
+ {-1 ,0}
+ };
+*** /usr/sys/conf/mips/files.mips.orig Sat Sep 11 06:09:28 1993
+--- /usr/sys/conf/mips/files.mips Fri Dec 9 09:32:01 1994
+***************
+*** 115,120 ****
+--- 115,122 ----
+ io/netif/if_ne.c optional ne device-driver Binary
+ io/netif/if_sl.c optional sl device-driver Binary Unsupported
+ io/netif/if_ppp.c optional ppp device-driver Notbinary
++ io/netif/ppp_tty.c optional ppp device-driver Notbinary
++ io/netif/bsd-comp.c optional ppp device-driver Notbinary
+ io/netif/slcompress.c optional sl or ppp device-driver Notbinary
+ io/netif/if_qe.c optional qe device-driver Binary
+ io/netif/if_uba.c optional inet device-driver Binary
projects / ppp.git / commitdiff