#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  ppp ppp/man ppp/man/ppp.devices.5 ppp/man/ppp.systems.5
#   ppp/man/intro.ms ppp/man/pppd.8 ppp/man/ppp.filter.5
#   ppp/man/ppp.dialers.5 ppp/man/tun.4 ppp/man/test.ms ppp/system
#   ppp/system/sun ppp/system/next ppp/system/sun/README
#   ppp/system/next/README
# Wrapped by bob@volitans on Wed Aug  7 16:24:38 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test ! -d 'ppp' ; then
    echo shar: Creating directory \"'ppp'\"
    mkdir 'ppp'
fi
if test ! -d 'ppp/man' ; then
    echo shar: Creating directory \"'ppp/man'\"
    mkdir 'ppp/man'
fi
if test -f 'ppp/man/ppp.devices.5' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/ppp.devices.5'\"
else
echo shar: Extracting \"'ppp/man/ppp.devices.5'\" \(2673 characters\)
sed "s/^X//" >'ppp/man/ppp.devices.5' <<'END_OF_FILE'
X.\" @(#)ppp.devices.5	1.4
X.TH PPP.DEVICES 5 "25 July 1991" "Morning Star PPP 1.0 Beta" "Morning Star Technologies"
X.SH NAME
Xppp.devices \- PPP physical device description file format
X.SH DESCRIPTION
XThe file
X.B /etc/ppp.devices
Xassociates dialer types with physical devices and speeds.  It is
Xexamined when
X.I pppd\^
Xneeds to originate a call to a neighboring machine.  If no suitable
Xspeed is found, or if all devices associated with that speed are busy, 
X.I pppd\^
Xwill try again later.
X.SH FORMAT
X.PP
XEntries are one to a line; blank lines are ignored.
XComments begin with a `#' and extend to the end of the line.
XUpper/lower case distinctions are significant.
XFields on a line are separated by horizontal white space (blanks or
Xtabs).
X.PP
XEach entry must contain three or more fields, in this order:
X.TP "\w'optional\ \ 'u"
Xdialer
XThe name of the modem dialing procedure description, found in
X.BR /etc/ppp.dialers ,
Xto use with this device
X.TP
Xdevice
XThe name of the device in the
X.B /dev
Xdirectory (
X.BR ttya , 
X.BR cua ,
Xetc.)
X.TP
Xspeed
XThis field is a string to be matched against the speed field of
Xentries in 
X.B /etc/ppp.systems
Xwhen the 
X.B /etc/ppp.systems
Xdevice field is set to ACU.  Speeds must either be valid async
Xbaud-rate numbers (as found in <sys/ttydev.h>) or must begin with them
X(2400, 38400, 19200-PEP, etc.)
X.TP
Xoptional parameters
XAny special handling for this device.  Currently supported values
Xinclude
X.RS
X.TP "\w'xonxoff\ \ \ 'u"
Xcrtscts
XSpecifies that the line be conditioned for out-of-band EIA RS-232
X`hardware' (RTS/CTS) flow control.  The default is to use no flow
Xcontrol.  For an outbound connection, this may be specified either in
X\fB/etc/ppp.devices\fP or on the \fIpppd\fP command line.
X.TP
Xxonxoff
XSpecifies that the line be conditioned for in-band (`software') flow
Xcontrol, using the characters DC3 (^S, XOFF, ASCII 0x13) to stop the
Xflow and DC1 (^Q, XON, ASCII 0x11) to resume.  The default is to use
Xno flow control.  For an outbound connection, this may be specified
Xeither in \fB/etc/ppp.devices\fP or on the \fIpppd\fP command line.
X.RE
X.SH EXAMPLE
X.RS
X.nf
X.ta \w''u \w'WDialerWW'u \w'WDialerWWdeviceWW'u \w'WDialerWWdeviceWW19200-PEPWW'u
X#
X#	/etc/ppp.devices - PPP devices file
X#
X#Dialer	device	speed	Optional parameters
XTB-PEP	cua	19200-PEP	crtscts
XTB-V32	cub	38400	crtscts
X.fi
X.RE
X.SH SEE ALSO
Xtun(4), 
X.\" ppp.devices(5), 
Xppp.dialers(5),
Xppp.filter(5),
Xppp.systems(5),
Xpppd(8), 
XRFC1171, 
XRFC1172, 
XRFC1144.
X.SH COPYRIGHT INFORMATION
XCopyright \(co 1991 Morning Star Technologies Inc.; all rights
Xreserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 ppp.devices.5"
X.\" End:
END_OF_FILE
if test 2673 -ne `wc -c <'ppp/man/ppp.devices.5'`; then
    echo shar: \"'ppp/man/ppp.devices.5'\" unpacked with wrong size!
fi
# end of 'ppp/man/ppp.devices.5'
fi
if test -f 'ppp/man/ppp.systems.5' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/ppp.systems.5'\"
else
echo shar: Extracting \"'ppp/man/ppp.systems.5'\" \(7925 characters\)
sed "s/^X//" >'ppp/man/ppp.systems.5' <<'END_OF_FILE'
X.\" @(#)ppp.systems.5	1.5
X.de SP
X.br
X.if t .sp .5v
X.if n .sp 1v
X..
X.TH PPP.SYSTEMS 5 "25 July 1991" "Morning Star PPP 1.0 Beta" "Morning Star Technologies"
X.SH NAME
Xppp.systems \- PPP neighboring systems description file format
X.SH DESCRIPTION
XThe file
X.B /etc/ppp.systems
Xdescribes how to connect with neighboring systems via PPP.
X.SH FORMAT
XEntries are one to a line; blank lines are ignored.
XComments begin with a `#' and extend to the end of the line.
XUpper/lower case distinctions are ignored in hostname specifications,
Xbut are significant elsewhere.
XFields on a line are separated by horizontal white space (blanks or
Xtabs).
X.PP
XEach entry must contain six fields, in the following order:
X.TP "\w'phone\ number\ \ \ 'u"
Xname
XThe name or IP address of the destination machine
X.TP 
Xwhen
XA string that indicates the days of the week and the times of day when
Xthe system can be called (for example, MoTuTh0800-1740).  The day
Xportion may be a list containing any of Su, Mo, Tu, We, Th, Fr or Sa.
XThe day may also be Wk for any weekday (same as MoTuWeThFr) or Any for
Xany day (same as SuMoTuWeThFrSa).
X.SP
XYou can indicate hours in a range (for example, 0800-1230).  If you do
Xnot specify a time, calls will be allowed at any time.
X.SP
XNote that a time range that spans 0000 is permitted.  For example,
X0800-0600 means that all times are allowed except times between 6 AM
Xand 8 AM.
X.SP
XMultiple date specifications that are separated by a vertical bar (|)
Xare allowed.  For example, Any0100-0600|Sa|Su means that the system
Xcan be called any day between 1 AM and 6 AM or any time on Saturday
Xand Sunday.
X.SP
XThe entire (sequence of) days and times may be followed by a semicolon
Xand the number of seconds before a failed call may be retried.  For
Xexample, Any;60 means call any time, but wait at least 60 seconds
Xafter a failure has occurred before trying to call again.  If a call
Xretry fails, \fIpppd\fP will double the delay before trying again.  If
Xno beginning call retry delay time is specified, 10 seconds is
Xassumed.
X.SP
XThe call retry delay time may be followed by a hyphen and the maximum
Xnumber of seconds to wait before trying to call again.  If a call
Xrepeatedly fails, the retry time will double with each call until it
Xreaches this value, after which the call will be retried every time
Xthe maximum number of seconds passes.  If no beginning call retry
Xmaximum backoff interval is specified, 3600 seconds is assumed.
X.TP
Xdevice
XIf set to ACU, any device in 
X.B /etc/ppp.devices
Xwith a matching speed may be used.  The
Xdevice's dialer chat script will be executed
Xfirst, followed by the 
X.B /etc/ppp.systems
Xchat script.  If set to the name of a device in the 
X.B /dev 
Xdirectory (
X.BR ttya ,
X.BR cua ,
Xetc.), then
X.B /etc/ppp.devices
Xand 
X.B /etc/ppp.dialers
Xwill not
Xbe consulted, and only the 
X.B /etc/ppp.systems
Xchat script will be executed.
X.TP
Xspeed
XThe baud rate.  If the device field is ACU, the speed field will be
Xstring matched against entries in 
X.BR /etc/ppp.devices .
XSpeeds must either be valid baud-rate numbers
Xor must begin with them (2400, 38400, 19200-PEP, etc.).
X.TP
Xphone number 
XThe value to replace the \fB\\T\fP escape sequence in the dialer script
X.TP
Xchat script 
XA description of the conversation that
X.I pppd\^
Xholds with the remote machine.
X.SH CHAT SCRIPT PARTICULARS
XA chat script takes the form of a word to expect
Xthe remote end to send, followed by a word to send in response.  After
Xeach `send' string that doesn't end with \fB\\c\fP,
X.I pppd\^
Xsends a carriage return character (ASCII 0x0d).
X.PP
XChat scripts are `expect send expect send ...'  or `expect-send-expect
Xsend ...', where the send following the hyphen is executed if the
Xpreceding expect fails.
X.PP
XCertain special words may be used in chat script `send' strings to
Xcontrol the behavior of
X.I pppd\^
Xas it attempts to dial.
X.RS
X.TP "\w'TIMEOUT \fItimeout-time\fP\ \ \ 'u"
XABORT \fIabort-string\fP
XIf
X.I pppd\^
Xsees \fIabort-string\fP while executing the remainder of the chat
Xscript, abort the dialing attempt and note the failure in the log
Xfile.
X.TP
XTIMEOUT \fItimeout-time\fP
XWhile executing the current chat script, wait \fItimeout-time\fP
Xseconds for a response before considering the dialing attempt to have
Xtimed out.
X.RE
X.PP
XThe expect-send couplet of \fB"" WORD\fP sets the line parity
Xaccordingly:
X.RS
X.TP "\w'P_EVEN\ \ \ 'u"
XP_ZERO
XSet the parity bit to zero.
X.TP
XP_ONE
XSet the parity bit to one.
X.TP
XP_EVEN
XTransmit characters with even parity.  This is the default.
X.TP
XP_ODD
XTransmit characters with odd parity.
X.RE
X.PP
XIn the midst of either an `expect' string or a `send' string, 
X\fB^\fP\fIx\^\fP gets translated into the appropriate control character,
Xand \fB\\\fP\fIx\^\fP gets translated into \fIx\^\fP.
XOther special sequences are:
X.RS
X.TP "\w'\\T\ \ \ \ 'u"
X\\s
XSend or receive a space character (ASCII 0x20)
X.TP
X\\t
XSend or receive a horizontal tab character (ASCII 0x09)
X.TP
X\\n
XSend or receive a linefeed character (ASCII 0x0a)
X.TP
X\\r
XSend or receive a carriage return character (ASCII 0x0d)
X.TP
X\\d
XDelay for two seconds before proceeding (send only)
X.TP
X\\c
XDon't append a carriage return character after sending this string
X.TP
X\\q
XDon't print succeeding send strings (e.g. passwords) in any debugging
Xoutput
X.RE
X.SH EXAMPLE
XIn the example below, we call host `everyone' using a Telebit PEP
Xmodem with its DTE interface set at 19200 bps.  We call host `nobody'
Xusing a V.32/V.42/V.42bis modem that's capable of driving a 38400 DTE,
Xand we are connected to host `someone' via a direct cable attached to
X/dev/ttya.
X.PP
XIf we are unsuccessful at connecting with `someone' we will try again
Xin two seconds.  If that attempt fails, we will wait four seconds
Xbefore the next attempt; then eight, then sixteen, then thirty two,
Xthen forty seconds.  We will continue attempting to contact `someone'
Xevery forty seconds.  Our retry intervals and maximum backoff values
Xfor `everyone' and `nobody' are the default `10-3600'.
X.PP
XThe notation "" "" means to expect nothing, then send nothing
X(followed by a carriage return).  The implicit carriage return is
Xoften useful for eliciting a response from a remote system.
X.PP
X.RS
X.nf
X#
X#	/etc/ppp.systems - PPP systems file
X#
Xeveryone Any ACU 19200-PEP 5551212  login: Pwe word: \\qfoObar
Xnobody Any ACU 38400 5551213 "" "" gin: Pthey word: \\qbaZz1ng
Xsomeone Any;2-40 cua 38400 0 ogin:--ogin: Pthem word: \\qmeumBle
X#
X.fi
X.RE
X.SH RECOMMENDATIONS
X.PP
XThe default retry time and backoff (i.e. Any;10-3600) are appropriate
Xin the case of a dedicated line between two systems, over which the
XPPP connection must normally be reestablished as quickly as possible
Xafter an interruption.  Moderate call retry times, such as 60 seconds,
Xwork well on systems that call each other on dialup modems, to avoid
Xdeadlocks waiting for telephone busy signals from each calling the
Xother at the same times.  Because of the difference between the
Xbehaviors of originating and answering modems, the 60-second clocks
Xwill usually start ticking at different times, allowing one side to
Xcall the other without interference.  Alternatively, different call
Xretry times may be specified at either end of a link to help keep
Xopposing ends of a link from calling the other end simultaneously.
X.PP
XIf you specify host names, be sure that their addresses are available
Xlocally, even with the connection down.  If you find that you must
Xbring up a connection to resolve a domain name, consider using that
Xhost's IP address (decimal numbers separated by periods) in both
X.B /etc/ppp.filter
Xand
X.B /etc/ppp.systems
Xinstead.
X.SH SEE ALSO
Xtun(4),
Xppp.devices(5), 
Xppp.dialers(5),
Xppp.filter(5),
X.\" ppp.systems(5),
Xpppd(8), 
XRFC1171, 
XRFC1172, 
XRFC1144.
X.\" .SH CREDITS
X.SH COPYRIGHT INFORMATION
XCopyright \(co 1991 Morning Star Technologies Inc.; all
Xrights reserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 ppp.systems.5"
X.\" End:
END_OF_FILE
if test 7925 -ne `wc -c <'ppp/man/ppp.systems.5'`; then
    echo shar: \"'ppp/man/ppp.systems.5'\" unpacked with wrong size!
fi
# end of 'ppp/man/ppp.systems.5'
fi
if test -f 'ppp/man/intro.ms' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/intro.ms'\"
else
echo shar: Extracting \"'ppp/man/intro.ms'\" \(37069 characters\)
sed "s/^X//" >'ppp/man/intro.ms' <<'END_OF_FILE'
X.\" @(#)intro.ms	1.8
X.\"
X.\" Pass me through tbl before handing me to troff with the -ms macro set
X.\"
X.\" Still to write:
X.\"	example crontab entry to clean up logfiles (like syslog.*)
X.\"	more and better hints and kinks about ppp.* configurations
X.\"	address and subnet assignment and routing strategies
X.\"	use for netmask argument
X.\"	NeXT configuration suggestions
X.\"	interoperability suggestions with NetBlazer & FTP Software
X.\"	more specific rc suggestions
X.\"	everything that new_state() does to the argv
X.\"	when the daemon supports it: UPAP and other authorization stuff
X.\"	ppp.auth(5)
X.\"
X.de SP
X.br
X.if t .sp .5v
X.if n .sp 1v
X..
X.de D1
X.if t .sp .5
X.if n .sp 1
X.RS
X.nf
X.ps -1
X..
X.de D2
X.fi
X.NL
X.RE
X.if t .sp .5
X.if n .sp 1
X..
X.ds CO (c)
X.if \w'\\(co'>0 .ds CO \\(co
X.\"
X.\"	N3 (good name, eh?) needs to be defined twice, else it doesn't
X.\"	work.  I don't know why.
X.\"
X.ds N3 \\uTM\\d
X.ds N3 \\uTM\\d
X.if t .ds N3 \\u\\s-2TM\\s+2\\d
X.LP
X\0
X.sp 2i
X.ND
X.ds CH
X.CD
X.ps \n(PS+\n(PS
XMorning Star PPP
X.NL
X
XVersion 1.0\(*b
X
X.ps \n(PS+\n(PS
X
XUser Guide
X
X.NL
XRevision 1.8
XAugust 6, 1991
X.DE
X.bp
X.LP
X\0
X.sp 2i
X.CD
X.SM
XCopyright \*(CO 1991 Morning Star Technologies, Inc.
XAll rights reserved
X
XPublished by
XMorning Star Technologies, Inc.
X1760 Zollinger Road
XColumbus, Ohio  43221
XUSA
X
X+1 614 451 1883 (voice)
X+1 800 558 7827 (voice)
X+1 614 459 5054 (FAX)
Xppp-beta@morningstar.com (e-mail)
X.NL
X.DE
X.bp
X.nr % 1
X.ds CF - % -
X.CD
X.B
XMorning Star PPP
X(Version 1.0\(*b\^)
XUser Guide (version 1.8)
X.R
X.DE
X.LP
X.ds CH \fBMorning Star PPP (Version 1.0\(*b\^) User Guide (version 1.8)\fP
X.NH 1
XIntroduction to PPP
X.LP
XMorning Star PPP provides an easy and flexible means of creating
Xwide-area TCP/IP based networks to transfer data between UNIX\**
X.FS
XUNIX is a registered trademark of AT&T.
X.FE
Xsystems, and between UNIX systems and others that also implement the
XInternet standard Point to Point Protocol.  Users of Morning Star PPP
Xcan connect their isolated UNIX systems to established TCP/IP
Xnetworks, or can connect geographically-separated networks.  Morning
XStar PPP can also run on a hub machine to provide dialin access to
Xmultiple remote systems.
X.LP
XSince they continue to use the UNIX host's native TCP/IP
Ximplementation and related utilities, users require no additional
Xtraining to make full use of the new link.  In fact, because of the
Xtransparency of TCP/IP internetwork routing, many may be unaware that
Xremote facilities are not connected to the local network.
X.LP
XBy contrast to network routers that requires an expensive leased line
Xto provide a constant connection, Morning Star PPP can establish the
Xlink when traffic demand warrants a call over standard telephone
Xlines.
XWhen the traffic has finished, Morning Star PPP will hang up the
Xconnection to save on telephone costs.
X.LP
XThe UNIX system administrator has complete control over the traffic
Xallowed to traverse the link.  Morning Star PPP can even turn a UNIX
Xsystem into a selective-isolation `firewall' gateway, enahancing the
Xsecurity provided to other systems on the local network.
X.LP
XMorning Star PPP implements HDLC address/control field and protocol
Xfield compression, as well as TCP header compression, to reduce
Xtransmission overhead to a minimum.  This improves both throughput and
Xinteractive response on typical modem connections.  Its interface to
Xthe UNIX host's TCP/IP implements Van Jacobson's TCP `fast queue'
Xscheme, whereby interactive packets are given priority for
Xtransmission on a congested link.
X.NH 1
XUsing this Manual
X.LP
XThe portions of this manual following this introductory User Guide
Xhave been organized in the style of the standard Berkeley UNIX manual
Xpages.  
XThe interface to the host UNIX system's IP implementation is described
Xin Section 4.
XSection 5 describes the format of the configuration files.  
XThe Morning Star PPP daemon itself is described in Section 8.
X.NH 1
XRelated Manuals
X.LP
XThe Morning Star PPP daemon is described in detail in the UNIX-style
Xmanual page \fBpppd\fP\^(8).  Its configuration files are described in
X\fBppp.devices\fP\^(5), \fBppp.dialers\fP\^(5), \fBppp.filter\fP\^(5),
Xand \fBppp.systems\fP\^(5).
XThe IP tunnel driver is described in \fBtun\fP\^(4).
X.LP
XHardware installation, when necessary, is described in the \fIHardware
XInstallation Guide\fP\^ for the Morning Star \fISnapLink\fP\^\** 
X.FS
XSnapLink is a registered trademark of Morning Star Technologies, Inc.
X.FE
XSCSI communications interface.  Not all Morning Star PPP installations
Xrequire additional hardware, so if you are using a serial port-only
Xproduct, you won't have received a copy of any \fIHardware
XInstallation Guide\fP\^.
X.LP
XThe authoritative references on TCP/IP and the Point-to-Point Protocol
Xare the Internet Requests for Comments series, particularly RFCs
X1171\**
X.FS
XPerkins, D., `Point-to-Point Protocol for the transmission of
Xmulti-protocol datagrams over Point-to-Point links', RFC 1171, Carnegie
XMellon University, July 1990.
X.FE
Xand
X1172\**.
X.FS
XPerkins, D. and Hobby, R., `The Point-to-Point Protocol (PPP) Initial
XConfiguration Options', RFC 1172, Carnegie Mellon University and the
XUniversity of California at Davis, July 1990.
X.FE
XThese are occasionally updated by the Point-to-Point Protocol Working
XGroup of the Internet Engineering Task Force (IETF), and are available
Xfrom the Network Information Center.  See the file \fBrfc-index\fP in
Xthe Morning Star PPP distribution directory for instructions on
Xacquiring an up-to-date copy.
X.LP
XTCP header compression is described in RFC 1144\**,
X.FS
XJacobson, V., `Compressing TCP/IP Headers for Low-Speed Serial Links',
XRFC 1144, Lawrence Berkeley Laboratory, February 1990.
X.FE
Xand reduces the number of protocol overhead bytes required for typical
Xpackets in a TCP data connection.
X.LP
XFast queueing for interactive TCP packets is described by its
Ximplementation in Van Jacobson's header-compressed SLIP\**.
X.FS
XJacobson, V., ftp.ee.lbl.gov:cslipbeta.tar.Z, if_sl.c, UTSL.
X.FE
X.NH 1
XSample Configuration
X.LP
XWe'll go through the steps necessary to configure a simple but
Xillustrative installation.  Our system, \fIrobin\fP\^, has a
XTelebit\**
X.FS
XTelebit is a trademark of Telebit Corporation.
X.FE
XT1600 asynchronous dialup modem on its /dev/ttya, which it uses for
Xits on-demand connection to \fIlark\fP\^.  It is also connected to an
Xadjacent machine, \fIsparrow\fP\^, via a short null-modem cable on its
X/dev/ttyb, which it uses for a connection that is constantly active.
X.NH 2
XUnpacking the distribution
X.LP
XYou received the software distribution as a \fBcompress\fP\^(1)ed
X\fBtar\fP\^(1) archive.  Create a working directory and unpack it:
X.D1
X% ls mstppp*
Xmst-sparc-ppp.tar.Z
X% mkdir /usr/local/src/ppp
X% cp mstppp.tar.Z /usr/local/src/ppp
X% cd /usr/local/src
X% zcat ppp/mstppp.tar.Z | tar xvf \-
X\fI...lots of output...\fP
X%
X.D2
X.NH 2
XInstalling the software and documentation
X.LP
XBecome the superuser, and run the installation shell script:
X.D1
X% su
XPassword: \fI(enter your \fBroot\fP password here)\fR
X# cd ppp
X# ./Install
X.D2
X.LP
XIf necessary, the \fBInstall\fP script will ask you questions about
Xyour system.  It will place the daemon into \fB/usr/etc/pppd\fP and
Xput the manual pages into the appropriate locations.  It will create a
Xshell script named \fBx25.uninstall\fP, to be used in case you need to
Xremove the software from your system.
X.NH 2
XBuilding and installing a kernel
X.LP
XThe contents of the file /usr/local/src/ppp/README will describe how
Xto configure and build a new kernel, move it into place, and reboot
Xyour system to ensure that it runs correctly.  If your system supports
Xdynamically loadable device drivers, you may need only to reboot for
Xthem to become available.
X.LP
XThe README file also describes how to configure the asynchronous
Xterminal interfaces on your machine, if any special arrangements are
Xnecessary.
X.NH 2
XArranging for PPP connections
X.LP
XOne tunnel driver must be installed in the kernel for each remote host
Xwith which we will establish a link, no matter which end of the link
Xinitiates the connection and no matter how many simultaneous links
Xwill be in operation.  To make configuration easier, if you say
X`pseudo-device tun' in the kernel configuration file, it will be the
Xsame as saying `pseudo-device tun16'.  This will allow you to grow up
Xto sixteen neighbors before rebuilding your kernel with a
Xspecification like `pseudo-device tun17'.
X.LP
XThe number of PPP neighbors a system can have is independent of the
Xnumber of serial ports it contains, though it is constrained to that
Xmany simultaneous connections.  Outbound PPP links (initiated by this
Xsystem) are independent of inbound PPP links (initiated by a neighbor
Xsystem).  If a link might be initiated upon demand in either
Xdirection, then each system must arrange for both an outbound and an
Xinbound connection.
X.NH 3
XArranging for outbound PPP connections
X.LP
XWhenever \fIrobin\fP is booted, one PPP daemon must be started for
Xeach outbound link.  In this case, since \fIrobin\fP will call
X\fIlark\fP on demand, we add the following lines to the appropriate
Xspot in \fIrobin\fP's boot-time shell script (\fB/etc/rc.local\fP on
Xour example machine):
X.D1
X.ta \w''u \w'if\ [\ \-f\ 'u \w'if\ [\ \-f\ if\ [\ \-f\ 'u \w'if\ [\ \-f\ pppd\ rob'u \w'if\ [\ \-f\ pppd\ rob(echo\ \-n\ \'\ pppd(sparrow)\')\ \ \ 'u
Xif [ \-f /usr/etc/pppd ]; then
X	if [ \-f /usr/adm/pppd.log ]; then
X		mv /usr/adm/pppd.log /usr/adm/OLDpppd.log
X	fi
X	pppd robin:sparrow auto up
X		(echo \-n ' pppd(sparrow)')	>/dev/console
X	pppd robin:lark auto
X		(echo \-n ' pppd(lark)')		>/dev/console
Xfi
X.D2
XThe daemons started here will look through \fB/etc/ppp.systems\fP to
Xfind entries for their destinations.
X.NH 3
XArranging for inbound PPP connections
X.LP
XAn account must be created for each machine that will initiate PPP
Xconnections to \fIrobin\fP.  In this case, since we expect \fIlark\fP
Xto dial us on demand, we add an entry to \fIrobin\fP's
X\fB/etc/passwd\fP file:
X.D1
X# cat >> /etc/passwd
XPlark::105:20:Lark's PPP login:/tmp:/usr/local/etc/ppplogin
X^D
X# passwd Plark
XNew password: \fIsome password\fP
XRetype new password: \fIsome password\fP
X#
X.D2
Xwhere \fB/usr/local/etc/ppplogin\fP is an executable shell script that
Xlooks like
X.D1
X# cat > /usr/local/etc/ppplogin
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty \-tostop
Xexec pppd `hostname`: idle 130 crtscts
X^D
X# chmod 755 /usr/local/etc/ppplogin
X#
X.D2
XThe PPP user's login shell script can, of course, be located anywhere
Xand be named almost anything; we just use the above for purposes of
Xillustration.  On a NeXT\**
X.FS
XNeXT is a trademark of NeXT Computer, Inc.
X.FE
Xworkstation, the name of the user's login shell script may not contain
Xthe letter `r', because of an undocumented feature that would cause
X/bin/sh to consider itself to be a security-restricted shell.
X.LP
XIn most cases, all inbound PPP logins can use the same ppplogin
Xscript.  If you want to ensure that only a particular host can use a
Xparticular login, then have that login account use a private
X\fB/usr/local/etc/ppplogin-\fIhost\fR that looks something like
X.D1
X# cat > /usr/local/etc/ppplogin-sparrow
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty \-tostop
Xexec pppd `hostname`:sparrow idle 130 crtscts
X^D
X# chmod 755 /usr/local/etc/ppplogin-sparrow
X#
X.D2
X.NH 2
XCreating the PPP configuration files
X.LP
XNow we can start building our configuration files.  See
X\fBppp.devices\fP\^(5), \fBppp.dialers\fP\^(5), \fBppp.filter\fP\^(5),
X\fBppp.systems\fP\^(5), and \fBpppd\fP\^(8) for a description of all
Xthe configuration options, and see the \fBExamples/\fP subdirectory in
Xthe software distribution for some example configurations.  (Each
Xcomplete entry in \fBppp.dialers\fP and \fBppp.systems\fP must be
Xtyped on a single line.  The \fBppp.dialers\fP example here is broken
Xto fit on the paper.)
X.D1
X# cd /etc
X# cat > ppp.devices
XTB-V32	cua	38400	crtscts
X^D
X# cat > ppp.dialers
XTB-V32	ABORT NO\\sCARRIER ABORT BUSY TIMEOUT 5 "" AT
X	OK-AT-OK ATZ OK \\c TIMEOUT 30 "" ATX1S111=0DT\\T
X	CONNECT \\c \\n
X^D
X# cat > ppp.filter
X.ta \w'default\ \ 'u \w'default\ \ bringup\ \ 'u
Xdefault	bringup	!ntp !3/icmp !who
X	pass	!who
X	keepup	!ntp !3/icmp !who
X	log	!nntp tcp/syn/recv
X^D
X# cat > ppp.systems
Xlark Any;50 ACU 38400 5551212 "" "" ogin: Probin word: \\qmypasswd
Xsparrow Anu;50 cub 38400 0 "" \\r\\r ogin: Probin word: \\qmypasswd
X^D
X# chmod 644 ppp.devices ppp.dialers ppp.filter
X# chmod 600 ppp.systems
X.D2
X.NH 2
XTesting the installation
X.LP
XOur PPP configuration is now complete, so we can go ahead and start it
Xup for testing:
X.D1
X# pppd robin:lark auto
X#
X.D2
XAnd make sure it got started:
X.D1
X# cat /usr/adm/pppd.log
X8/5-11:08:36-5997 Morning Star Technologies PPP
X8/5-11:08:36-5997 Version 1.0 Beta [2-Aug-1991 13:09:10]
X8/5-11:08:36-5997 du0: pppd robin:lark auto 
X#
X.D2
XAnd bring up the link: 
X.D1
X# telnet lark
XTrying lark ...
XConnected to lark.
XEscape character is '^]'.
X
X
XSunOS 4.1 UNIX (lark) (ttyp3)
X
Xlark login: ^DConnection closed by foreign host.
X#
X.D2
XAnd watch how the link was initiated:
X.D1
X# cat /usr/adm/pppd.log
X8/5-11:08:36-5997 Morning Star Technologies PPP
X8/5-11:08:36-5997 Version 1.0 Beta [2-Aug-1991 13:09:10]
X8/5-11:08:36-5997 du0: pppd robin:lark auto 
X8/5-11:08:45-5997 tcp 137.175.2.11/1204 \-> 131.187.1.131/telnet 40 syn bringup
X8/5-11:08:45-5997 Dialing lark (cua/38400/5551212/TB-V32)
X8/5-11:09:23-5997 Call succeeded
X8/5-11:09:37-5997 PPP connected to lark
X8/5-11:10:34-5997 tcp 137.175.2.2/smtp <- 129.221.8.2/2547 40 syn
X#
X.D2
XThis log file snippet shows that our \fItelnet\fP session to
X\fIlark\fP was the cause for the link being initiated.  It also shows
Xthat the `log' line in \fBppp.filter\fP is operating as expected, and
Xthat the first incoming TCP connection was to deliver mail.
X.LP
XMorning Star PPP is installed, configured, running and connected on
Xboth of our links.  When the link is up, users should be able to
Xaccess \fIrobin\fP from a remote machine via \fIrlogin\fP\^.  You
Xshould also be able to \fItelnet\fP, \fIftp\fP, etc. between the two.
XIf either machine is connected to a local area network, you can set
Xset up IP routing on the two networks so that hosts on either can
Xcommunicate with hosts on the other, using the machines on the ends of
Xthe PPP link as routers.
X.\" 
X.\" .NH 1
X.\" IP Routing tips
X.\" .LP
X.\" Watch this space...
X.\" .NH 1
X.\" Finer points of the configuration files
X.\" .LP
X.\" Just keep playing with them, you'll get it right eventually.  Watch
X.\" this space for hints.
X.NH 1
XObservations about on-demand dialup IP
X.NH 2
XApplication behavior
X.LP
XThe scheme used to support on-demand dialups in Morning Star PPP
Xdepends upon network- and higher-layer protocol timeouts being
Xtypically longer than the time needed to allocate a modem, dial it,
Xcomplete the call, login to the remote system, start up the PPP
Xprotocol handler there, and establish LCP and IPCP connectivity.  This
Xis a reasonable assumption, since a local call will typically require
Xabout 25 seconds between the daemon's receipt of the first `bringup'
Xpacket and the establishment of IP-level connectivity (of that, more
Xthan 20 are consumed with dialing the call and training the modems).
XThis scheme works even if the first remote modem is busy and the
Xdialing pppd must try a second telephone number, so long as the dialer
Xscript is carefully written to include appropriate ABORT and TIMEOUT
Xstrings.  The user's application will simply wait for the connection
Xto be established and continue as if the connection had always been in
Xplace.  This even works well when a link times out with active TCP
Xsessions in place, such as a \fItelnet\fP connection to the remote
Xend.  When the user types, or when an application writes output, a new
Xcall is placed from either end and the session is re-established
Xwithout TCP or the application above it noticing anything was amiss.
X.SP
XUnfortunately, if the connection cannot be re-established, TCP will
Xtime out and the application may fail ungracefully.  This most often
Xhappens during times of resource contention (no free modems to place
Xor answer the call) or acute connectivity problems (telephone system
Xcall-routing breakdown or extreme service degradation).  The effect
Xwill be the same as if the machine at the `other' end had crashed
Xungracefully, since the application will only be able to tell that it
Xis unable to exchange packets with its partner.
X.\" Someday we'll implement ICMP Unreachables.
X.NH 2
XDealing with bandwidth limitations
X.LP
XThe Internet's TCP/IP protocol suite is remarkably flexible and
Xrobust, with a wide variety applications for use over media ranging
Xfrom multigigabit data superhighways to long-delay satellite channels
Xto local area networks to dialup modems to amateur radio to carrier
Xpigeons\**.
X.FS
XWaitzman, D., `Standard for the transmission of IP datagrams on avian
Xcarriers', RFC 1149, BBN, April 1990.
X.FE
XWhile by definition all IP-based applications may be transparently
Xused over links traversing any combination of media, some applications
Xare better suited to media with the relatively low bandwidth and
Xmoderate latency and delay characteristics of asynchronous dialup
Xconnections.
X.NH 3
XApplications with few problems on thin wires
X.LP
XPPP over current-technology dial modems\**
X.FS
XCCITT V.32 (9600 baud) or V.32bis (14400 baud) carrier, with V.42
Xerror correction and V.42bis data compression, and the host serial
Xinterface latched at 38400 baud
X.FE
Xprovides satisfactory performance for most typical TCP/IP and UDP/IP
Xwide-area applications.  Especially with TCP header compression, users
Xwill experience useful file transfer throughput (V.32/V.42bis yields
X1.7\-2.8 Kbytes/sec for a typical large binary data file) and
Xreasonable interactive response in applications such as \fItelnet\fP,
X\fIrlogin\fP, and the like.  Plenty of bandwidth is available for
Xnetwork infrastructure applications such as SMTP electronic mail, NNTP
Xnetwork news, NTP clock synchronization, domain name service, etc.
X.NH 3
XApplications with some problems on thin wires
X.LP
XThe speed limitation of the dialup medium becomes more apparent when
Xlarger amounts of data are transferred, particularly for interactive
Xapplications such as \fIxterm\fP or other display-oriented programs.
XWhile large bitmap editors and CAD packages will operate correctly,
Xusers may find that the modem simply isn't able to keep up with their
Xdemands for interactive responsiveness.
X.\" The need for more PPP bandwidth will be addressed in future
X.\" Morning Star products, both for dialup and for leased-line applications.
X.NH 3
XApplications to avoid on thin wires
X.LP
XApplications that are extreme users of communications bandwith, such
Xas Sun's Network File System (NFS\**), 
X.FS
XNFS is a trademark of Sun Microsystems, Inc.
X.FE
Xshould be avoided over dialup links except in cases of dire necessity.
XNot only is NFS able to easily overwhelm a modem link, it is a
XUDP-based application, so the user will not enjoy the packet overhead
Xreduction benefits of TCP header compression.  While performance may
Xbe marginally acceptable for read-only file access, NFS's synchronous
Xwrite semantics will make file creation and writing quite painful.
XAttempting to execute a program stored on a remotely-mounted
Xfilesystem will have this same problem, since it will be swapped to
Xthe same file from which it was read.
X.SP
XFortunately, there are usually other approaches, more appropriate for
Xwide-area networking over low-bandwith links, to solving the problems
Xthat NFS addresses.  Use Berkeley's \fIrdist\fP system to keep the
Ximportant segments of two sites' file structures in reasonable
Xsynchrony.  Also, use a package like ange-ftp.el\**
X.FS
XWritten by Andy Norman <ange@hplb.hpl.hp.com>, available from
Xftp.cis.ohio-state.edu:pub/gnu/emacs/elisp-archives/packages/ange-ftp.el.Z
X.FE
Xin your GNU Emacs to automatically manage FTP connections that are
Xtransparently associated with your editing buffers.  This gives the
Xappearance of the ability to edit files while they reside on a remote
Xmachine, without needing to use NFS to mount the remote filesystems
Xlocally.
X.SP
XIf, even after the above attempts at dissuasion, you still think that
Xyou absolutely must use NFS, set the \fIrsize\fP and \fIwsize\fP
Xparameters on the mount request to something like 1400 (to fit safely
Xwithin the usual PPP MRU/MTU of 1500, even with possible
Xspecial-character escaping as per the \fIasyncmap\fP\^), and increase
Xthe \fItimeo\fP timeout parameter to accomodate network delays.
X.NH 1
XCabling
X.LP
XMost systems and modems use the EIA RS-232\**
X.FS
XElectronic Industries Association, EIA Standard RS-232-C, `Interface
XBetween Data Terminal Equipment and Data Communications Equipment
XEmploying Serial Binary Data Interchange', August 1969.
X.FE
Xsignalling conventions for their asynchronous serial ports.  In the
Xtables below, there is no difference between the pins referred to as
X`DTE pins' or `Modem pins', nor between `Local pins' and `Remote
Xpins', except notational convenience.  If a cable has the same
Xphysical connector type on each end (both DB-25 or both MiniDIN-8), it
Xis completely symmetrical and may be flipped end-for-end with no
Xeffect.
X.NH 2
XAsynchronous Modem cables
X.LP
XIf your system is to be connected to an asynchronous modem, and if the
Xsystem uses DB-25 connectors, the pins on the system (DTE) end of the
Xcable should be connected straight through to the same-numbered pins
Xon the DB-25 modem end.
X.KS
XIn order of importance for proper operation, the pins you should
Xconnect are
X.TS
Xcenter tab (\);
Xlb lb lb lb
Xl  l  l  l .
XT{
XDTE
X.br
XDB-25
X.br
Xpin
XT}\T{
XRS-232 Signal
XT}\T{
XModem
X.br
XDB-25
X.br
Xpin
XT}\Direction
X1\Protective Ground\1\both
X7\GND (Signal Ground)\7\both
X2\TD (Transmit Data)\2\from DTE
X3\RD (Receive Data)\3\from Modem
X6\DSR (Data Set Ready)\6\from Modem
X20\DTR (Data Terminal Ready)\20\from DTE
X4\RTS (Request To Send)\4\from DTE
X5\CTS (Clear To Send)\5\from Modem
X8\DCD (Data Carrier Detect)\8\from Modem
X22\RI (Ring Indicator)\22\from Modem
X.TE
X.KE
X.KS
X.LP
XNeXTstations' serial ports have MiniDIN-8 connectors.  A cable to
Xconnect a NeXTstation to a DB-25 asynchronous modem looks like\**
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XT{
XDTE
X.br
XMiniDIN-8
X.br
Xpin
XT}%T{
XRS-232
X.br
XSignal
XT}%T{
XModem
X.br
XDB-25
X.br
Xpin
XT}%Direction
X1%DTR%20%from DTE
X2%DCD%8%from Modem
X3%TD%2%from DTE
X4%GND%7%both
X5%RD%3%from Modem
X6%RTS%4%from DTE
X7%\fIN/C\fP%\fIN/C\fP%\fIN/C\fP
X8%CTS%5%from Modem
X\fIN/C\fP%DSR%6%from Modem
X\fIN/C\fP%RI%22%from Modem
X.TE
X.KE
X.FS
X`Network and System Administration', Chapter 13 `Attaching Peripheral
XDevices', section on `Serial Port Connector and Cable Specifications',
Xpps 186\-188, NeXT Computer Inc., 1990.
X.FE
X.NH 2
XAsynchronous `Null-Modem' cables
X.LP
XIf your system is to be connected directly to another system, the pins
Xon the local system's end of the cable should be connected with the
Xsymmetric-function pins on the remote system's end.  This is commonly
Xcalled a null-modem cable.
X.KS
XIn order of importance for proper operation, the pins you should
Xattach between two systems with DB-25 connectors are
X.TS
Xcenter tab (\);
Xlb lb lb lb
Xl  l  l  l .
XT{
XLocal
X.br
XDB-25
X.br
Xpin
XT}\T{
XLocal
X.br
XRS-232
X.br
XSignal
XT}\T{
XRemote
X.br
XDB-25
X.br
Xpin
XT}\T{
XRemote
X.br
XRS-232
X.br
XSignal
XT}
X1\Protective Ground\1\Protective Ground
X7\GND\7\GND
X2\TD\3\RD
X3\RD\2\TD
X6\DSR\20\DTR
X20\DTR\6\DSR
X4\RTS\5\CTS
X5\CTS\4\RTS
X.TE
X.KE
X.KS
X.LP
XNeXTstations' serial ports have MiniDIN-8 connectors.  A cable to
Xconnect a NeXTstation to another system that has DB-25 connectors
Xlooks like
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XT{
XLocal
X.br
XMiniDIN-8
X.br
Xpin
XT}%T{
XLocal
X.br
XRS-232
X.br
XSignal
XT}%T{
XRemote
X.br
XDB-25
X.br
Xpin
XT}%T{
XRemote
X.br
XRS-232
X.br
XSignal
XT}
X1%DTR%8%DCD
X2%DCD%20%DTR
X3%TD%3%RD
X4%GND%7%GND
X5%RD%2%TD
X6%RTS%5%CTS
X7%\fIN/C\fP%\fIN/C\fP%\fIN/C\fP
X8%CTS%4%RTS
X\fIN/C\fP%DSR%6%DSR
X\fIN/C\fP%RI%22%RI
X.TE
X.KE
X.KS
X.LP
XA cable to connect a pair of NeXTstations looks like
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XT{
XLocal
X.br
XMiniDIN-8
X.br
Xpin
XT}%T{
XLocal
X.br
XRS-232
X.br
XSignal
XT}%T{
XRemote
X.br
XMiniDIN-8
X.br
Xpin
XT}%T{
XRemote
X.br
XRS-232
X.br
XSignal
XT}
X1%DTR%2%DCD
X2%DCD%1%DTR
X3%TD%5%RD
X4%GND%4%GND
X5%RD%3%TD
X6%RTS%8%CTS
X7%\fIN/C\fP%7%\fIN/C\fP
X8%CTS%6%RTS
X.TE
X.KE
X.NH 1
XFlow control
X.LP
XIf your UNIX system supports it, use out-of-band `hardware' (RTS/CTS)
Xflow control between your system and your modem, or between two
Xsystems over a null-modem cable.  On a Sun system, specify `crtscts'
Xeither on the \fIpppd\fP command line, or in the Optional Parameters
Xfield of the line in \fBppp.devices\fP\^(5).  On a NeXTstation,
Xspecify `cufa' in the Device field in \fBppp.devices\fP\^(5).
X.LP
XIf, for whatever reason, you are forced to use in-band `software'
X(XON/XOFF, ^Q/^S) flow control, then specify `xonxoff' on the
X\fIpppd\fP command line or in \fBppp.devices\fP\^(5), and
Xuse `cua' on a NeXT.
X.LP
XThe default is to use no flow control.
X.LP
XSunOS 4.1.1 implements hardware flow control on the native CPU serial
Xports only for transmission\**.
X.FS
XSee the Output Modes section of \fBtermio\fP\^(4) and the IOCTLS section of
X\fBzs\fP\^(4s).
X.FE
XWorkstations running this OS respect the modem's use of CTS to
Xindicate its readiness to receive characters from the host, but do not
Xuse RTS to throttle the modem's data stream to the host.  This means
Xthat when presented with a heavy incoming traffic load, the Sun's
Xnative CPU serial ports will be overloaded, and the console will
Xreport a series of occasional `zs1: silo overflow' errors.  This is
Xunfortunate but unavoidable by PPP, introduces no errors into the data
Xbeing transferred across the network, and does not measurably affect
Xthe PPP link's throughput or responsiveness.
X.NH 1
XModem parameters
X.NH 2
XGeneral Recommendations
X.LP
XYou should connect your modem to your computer at the highest
Xasynchronous serial speed that both can support (typically 38400 baud,
Xas found in /usr/include/sys/ttydev.h), and allow the modem's internal
Xcarrier speed matching capability to make a usable connection with
Xwhatever type of modem is in use at the other end.  This will allow
Xyou to take maximum advantage of the modem's data compression
Xcapabilities.  
X.LP
XIf your modem supports error correction, you should enable its use.
XThis will allow line noise problems to be corrected at as low a level
Xin the protocol stack as possible.  If the modem has both MNP\**
X.FS
XMNP is a trademark of Microcom Inc.
X.FE
Xlevel
X4 and CCITT V.42, choose the latter so that you can also use CCITT
Xdata compression.
X.LP
XIf your modem supports data compression, you probably should enable
Xits use unless your tests show your application has preferable
Xperformance attributes without it.  This will allow you to pass as
Xmuch information across the PPP line as possible.  If the modem has
Xboth MNP5 and CCITT V.42bis, choose the latter because it has a higher
Xmaximum compression ratio and because it behaves better with
Xprecompressed data streams.
X.NH 2
XSpecific examples
X.LP
XIn the file \fBExamples/ppp.dialers.ex\fP you'll find dialer
Xdescriptions for a few types of modems.  Since your modems will likely
Xbe used for purposes besides PPP (e.g. UUCP or interactive users),
Xit's best to set them up for efficiency in all possible uses.  The
XPPP-specific register settings in ppp.dialers ensure that an otherwise
Xgeneral-purpose modem will work as well as possible with PPP, for the
Xduration of the PPP session.
X.LP
XIn the examples below, we'll show how to configure a typical modern
Xmodem, including a picture of its working register settings and a
Xcommand string that will set it up correctly.  We'll also describe
Xwhat each of those register settings mean, so that if you use a
Xdifferent type of modem, you should be able to set it up similarly.
X.KS
X.LP
XWe find that a Telebit T1600 works well with the following register
Xsettings:
X.D1
X.ta \w''u \w'S000=000\ 'u \w'S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u \w'S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ S000=000\ 'u
XOK
Xat&v
XT1600 \- Version LA1.00  \- Active Configuration
X B1  E1  L3  M0  Q2  T   V1  X12  Y0
X&C1 &D3	&G0 &J0	&L0 &Q0	&R3 &S1	&T4 &X0
XS000:1	S001=0	S002=43	S003=13	S004=10	S005=8	S006=2	S007:120
XS008=2	S009=6	S010=14	S011=70	S012=50	S018=0	S025=5	S026=1
XS038=0	S041=0	S045=0	S046=0	S047=4	S048=0	S050=0	S051:6
XS056=17	S057=19	S058:2	S059:15	S060=0	S061:0	S062=15	S063:2
XS064=0	S068=255	S069=0	S090=0	S093=8	S094=1	S100=0	S102=0
XS104=0	S105=1	S111:0	S112=1	S180=2	S181=1	S183=25	S190=1
XS253=10	S254=255	S255=255
XOK
X.D2
X.KE
X.SP
XYou can make a T1600 work like this by giving it the following
Xcommand:
X.D1
Xat&fs0=1s7=120s51=6s58=2s59=15s61=0s63=2s111=255l3m0q2tx12&c1&d3&s1&w
X.D2
X.SP
XThis accomplishes the following:
X.RS
X.IP "&f" "\w's111=255\ \ 'u"
XLoads factory default settings.
X.IP "s0=1"
XAnswer after one ring.
X.IP "s7=120"
XWait 120 seconds for a valid carrier tone to be sent from the remote
Xmodem.
X.IP "s51=6"
XLatch the DTE interface at 38400 bps.
X.IP "s58=2"
XUse full-duplex RTS/CTS flow control.  When RTS is OFF, the modem will
Xnot send data to the local DTE.  When RTS is ON the modem sends data
Xto the local DTE.
X.IP "s59=15"
XUse the following result code suffixes:
X.RS
X.nf
XPossible link protocol suffixes: nothing, REL, or LAPM
XPossible compression suffixes: nothing or COMP
X.fi
X.RE
X.IP "s61=0"
XLocal reaction to a break signal on the serial interface is the same
Xas specified in S63.
X.IP "s63=2"
XWhen a break signal is transmitted by the local DTE during an error
Xcontrolled connection, the modem will discard any buffered data and
Xsend the break.
X.IP "s111=255"
XUse the file transport protocol spoofing mechanism specified by the
Xremote modem.  If both modems have S111=255, no protocol is spoofed.
X.IP "l3"
XSets the speaker volume high.
X.IP "m0"
XTurns off the speaker.
X.IP "q2"
XModem reports result codes when originating a call, but does not
Xreturn result codes when answering a call.
X.IP "t"
XModem uses DTMF tone dialing.
X.IP "x12"
XResult codes include the following:
X.RS
X.\" .nf
XBUSY,
XDIALING,
XERROR,
XNO CARRIER,
XNO DIALTONE,
XOK,
XRING,
XRRING,
X.br
XCONNECT 300,
XCONNECT 1200,
XCONNECT 2400,
XCONNECT 4800,
XCONNECT 7200,
XCONNECT 9600,
XCONNECT 12000,
XCONNECT 14400,
XCONNECT 19200, and
XCONNECT 38400.
X.\" .fi
X.RE
X.IP "&c1"
XWhen a carrier is detected from the remote modem, the DCD signal is
Xturned ON after the CONNECT result code is sent to the DTE.  The DCD
Xsignal is turned OFF when the carrier is dropped.
X.IP "&d3"
XThe modem resets and enters command mode when the DTR signal is
Xswitched from ON to OFF.  This causes the modem to recall the current
Xuser configuration parameters from nonvolatile memory.
X.IP "&s1"
XDSR is ON after the answer tone is detected and stays ON throughout
Xthe connection.
X.IP "&w"
XSaves the current configuration settings to nonvolatile RAM.
X.RE
X.LP
XIf you have some other sort of modem that's not described here, you
Xshould configure it with similar functions (e.g. RTS/CTS flow control)
Xusing that modem's own command set and register semantics.
X.NH 1
XInteroperability with other PPP implementations
X.NH 2
XThe Telebit NetBlazer\**
X.FS
XNetBlazer is a trademark of Telebit Corporation.
X.FE
X.LP
XMorning Star PPP has been tested with version 1.20 of Telebit's
XNetBlazer software.
XWe were unable to configure the NetBlazer to negotiate the use of RFC
X1144 `VJ' TCP header compression, though we are assured that future
Xversions of the NetBlazer software will incorporate this feature.  It
Xwill probably not require the use of \fBpppd\fP\^'s `old' argument.
X.NH 3
XDialing into a NetBlazer from a UNIX system
X.LP
XThis would be the arrangement to allow several remote workstations to
Xdial into a NetBlazer serving as a hub.
X.NH 4
XConfiguring the NetBlazer
X.LP
XThe NetBlazer may be set up as if the UNIX machine were just another
Xremote `dynamic-interface' NetBlazer, using the PPP encapsulation
Xprotocol in `packet mode'.
X.LP
XConfigure the NetBlazer as described in chapter 3 of the NetBlazer
XReference Manual, noting particularly the discussion of the
X\fBipdial\fP command in the section on Setting Up Remote IP
XDestinations.  When queried for `Name of dial IP interface to add',
Xrespond with the name of the UNIX system.  Morning Star PPP does not
Ximplement a `crypto handshake' to exchange with the NetBlazer.  Use
XPPP rather than SLIP, and specify 1500 for the MTU.  When asked to
Xenter the password for the dial-in user for use by the UNIX system,
Xnote that password for later inclusion in the UNIX system's
X\fB/etc/ppp.systems\fP entry that describes how to dial into this
XNetBlazer.
X.NH 4
XConfiguring the UNIX system
X.LP
XIn your UNIX system's \fB/etc/ppp.systems\fP\^, the username provided
Xby the login portion of the chat script will be the name of the UNIX
Xsystem itself.  The password will be the one provided when arranging
Xfor the dial-in user on the NetBlazer.
X.LP
XIn your UNIX system's \fB/etc/rc.local\fP\^, start the Morning Star
XPPP daemon with the `active' argument, because the NetBlazer starts in
Xthe LCP Passive-Open state.
X.D1
Xpppd `hostname`:remote-netblazer auto active idle 130
X.D2
X.NH 3
XDialing into a UNIX system from a NetBlazer
X.LP
XThis would be the arrangement to allow a hub NetBlazer to connect on
Xdemand to several remote workstations.  \fI(This direction hasn't all
Xbeen worked out quite yet.)\fP
X.NH 4
XConfiguring the UNIX system
X.LP
XIn order to accomodate a NetBlazer dialing into a UNIX system running
XMorning Star PPP, the following changes must be made to the UNIX
Xsystem.  Make an entry in /etc/gettytab that's a duplicate of the
Xentry you would normally have used, except with the addition of the
X\fB:p8:\fP parameter (see \fBgettytab\fP\^(5)), like this:
X.D1
Xh|std.38400|38400-baud:sp#38400:
Xw|P.38400|38400-baud:sp#38400:p8:
X.D2
XThen change /etc/ttytab to use the new entry, like this:
X.D1
X.ta \w'#ttya\ \ 'u \w'#ttya\ \ "/usr/etc/getty std.38400"\ \ 'u \w'#ttya\ \ "/usr/etc/getty std.38400"\ \ dialup\ \ 'u
X#ttya	"/usr/etc/getty std.38400"	dialup	on # T1600
Xttya	"/usr/etc/getty P.38400"	dialup	on # T1600
X.D2
X.LP
XThe login shell script for the NetBlazer's incoming connection must
Xtell the NetBlazer what it expects to hear ("Packet mode enabled")
Xbefore starting the PPP LCP option negotiation phase of the
Xconnection.  Since the NetBlazer does not perform IPCP `IP-Addresses'
Xnegotiation, the UNIX PPP must tell the NetBlazer what IP address it
Xshould be.
X.D1
X# cat > /usr/local/etc/ppplogin-netblazer
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty \-tostop
Xecho "Packet mode enabled"
Xexec pppd `hostname`:remote-netblazer idle 130 crtscts timeout 15
X^D
X# chmod 755 /usr/local/etc/ppplogin-netblazer
X#
X.D2
XThe name \fIremote-netblazer\fP in the above shell script should be
Xreplaced with the IP address of the NetBlazer that will be connecting,
Xor its name if its address can be found in the local hosts table or
Xcan be resolved by the local name server before the NetBlazer link is
Xavailable.
X.NH 4
XConfiguring the NetBlazer
X.LP
XChange the ICS entry in the NetBlazer's chat.txt file so that it looks
Xfor `word:' rather than `password:' in the e4 line.  This is because
Xsome UNIX \fIlogin\fP programs say `Password:' with a capital `P',
Xwhich won't match the NetBlazer's desired lower-case `p'.  Looking for
Xthe string `word:' should work correctly in any case, and will not
Xaffect the NetBlazer's operation in general.
X.LP
XYou may also need to extend the timeout period of the e7 line to
Xsomething like
X.D1
Xe7,20,30,99,Packet mode enabled
X.D2
XThis similarly will not adversely affect the NetBlazer's operation.
X.NH 2
XFTP Software Inc's PC/TCP\** Network Software for DOS
X.FS
XPC/TCP and FTP Software are registered trademarks of FTP Software, Inc.
X.FE
X.LP
XMorning Star PPP is being tested with version 2.05 of FTP Software
XInc's PC/TCP PPP (PC-227) implementation.
X.NH 3
XGetting ready for a PC to dial into a UNIX system
X.LP
XWatch this space...
X.NH 3
XGetting a PC ready to dial into a UNIX system
X.LP
XWatch this space...
X.NH 1
XCredits
X.LP
XParts of the protocol engine are derived from code written by Drew D.
XPerkins, ddp@andrew.cmu.edu, now ddp@interstream.com.
X.NH 1
XCopyright Information
X.LP
XThis software is Copyright 1991 Morning Star Technologies, all rights
Xreserved.  It contains software developed at Carnegie Mellon
XUniversity which is Copyright 1989 Carnegie Mellon University, all
Xrights reserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -t -ms -TX75 intro.ms"
X.\" End:
END_OF_FILE
if test 37069 -ne `wc -c <'ppp/man/intro.ms'`; then
    echo shar: \"'ppp/man/intro.ms'\" unpacked with wrong size!
fi
# end of 'ppp/man/intro.ms'
fi
if test -f 'ppp/man/pppd.8' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/pppd.8'\"
else
echo shar: Extracting \"'ppp/man/pppd.8'\" \(8053 characters\)
sed "s/^X//" >'ppp/man/pppd.8' <<'END_OF_FILE'
X.\" @(#)pppd.8	1.8
X.de SP
X.br
X.if t .sp .5v
X.if n .sp 1v
X..
X.TH PPPD 8 "7 August 1991" "Morning Star PPP 1.0 Beta" "Morning Star Technologies"
X.SH NAME
Xpppd \- PPP daemon
X.SH SYNOPSIS
X.B pppd
X[\^\fBnooptions\fR\^]
X[\^\fBnoaccomp\fR\^]
X[\^\fBnoprotcomp\fR\^]
X[\^\fBnovjcomp\fR\^]
X[\^\fBnoasyncmap\fR\^]
X[\^\fBasyncmap\fR \^async-map\^]
X[\^\fBnoipaddress\fR\^]
X[\^\fBnetmask\fR \^subnet-mask\^]
X[\^\fBnomagic\fR\^]
X[\^\fBnomru\fR\^]
X[\^\fBmru\fR \^mru-size\^]
X.\" [\^\fBrequireupap\fR\^]
X.\" [\^\fBnoupap\fR\^]
X[\^device\^]
X[\^comm-speed\^]
X[\^\fBcrtscts\fR\^]
X[\^\fBxonxoff\fR\^]
X[\^local:\^[remote\^]\^]
X[\^\fBauto\fR\^]
X[\^\fBup\fR\^]
X[\^\fBnodetach\fR\^]
X[\^\fBactive\fR\^]
X[\^\fBpassive\fR\^]
X[\^\fBold\fR\^]
X[\^\fBlog\fR \^log-file\^]
X.\" [\^\fBnolog\fR\^]
X[\^\fBfilter\fR \^filter-file\^]
X[\^\fBidle\fR \^idle-time\^]
X[\^\fBtimeout\fR \^restart-time\^]
X[\^\fBdebug\fR \^debug-level\^]
X.SH DESCRIPTION
X.I pppd\^
Xis a daemon process used in UNIX\*R systems to manage a connection to
Xanother host using PPP, the Point to Point Protocol.  It uses the UNIX
Xhost's native serial ports.  It communicates with the UNIX kernel's
Xown TCP/IP implementation via the Morning Star IP tunnel driver.
X(see
X.IR tun\^ (4))
X.SH OPTIONS
X.TP "\w'\fBnetmask\fP\ \ \fRsubnet-mask\fP\ \ 'u"
X.B nooptions
XDisable all LCP and IPCP options
X.TP
X.B noaccomp
XDisable HDLC Address and Control Field compression.
X.TP
X.B noprotcomp
XDisable LCP Protocol Field Compression.
X.TP
X.B novjcomp
XDisable RFC1144 Van Jacobson TCP header compression.
X.TP
X.B noasyncmap
XDisable LCP Async Control Character Map negotiation.
X.TP
X.B asyncmap\ \fRasync-map\fP
XSet the desired Async Control Character Map to async-map, expressed in
Xhexadecimal (default 0xA0000).
X.TP
X.B noipaddress
XDisable IPCP IP Address negotiation.
X.TP
X.B netmask\ \fRsubnet-mask\fP
XSet the subnet mask of the interface to subnet-mask, expressed either
Xin hexadecimal (e.g. 0xffffff00) or in dotted-quad notation (e.g.
X255.255.255.0).  The default subnet mask will be appropriate for the
Xnetwork (class A, B, or C), assuming no subnetting.
X.TP
X.B nomagic
XDisable LCP Magic Number negotiation.
X.TP
X.B nomru
XDisable LCP Maximum Receive Unit negotiation (demand 1500).
X.TP
X.B mru\ \fRmru-size\fP
XSet LCP Maximum Receive Unit value to mru-size for negotiation
X(default 1500).
X.TP
Xdevice
XCommunicate over the named device (default /dev/tty).
X.TP
Xcomm-speed
XSet communications rate to comm-speed bits per second.
X.TP
X.B crtscts
XCondition the line for out-of-band EIA RS-232 `hardware' (RTS/CTS)
Xflow control.  The default is to use no flow control.  For an outbound
Xconnection, this may be specified either in \fB/etc/ppp.devices\fP or
Xon the \fIpppd\fP command line.
X.TP
X.B xonxoff
XCondition the line for in-band (`software') flow control, using the
Xcharacters DC3 (^S, XOFF, ASCII 0x13) to stop the flow and DC1 (^Q,
XXON, ASCII 0x11) to resume.  The default is to use no flow control.
XFor an outbound connection, this may be specified either in
X\fB/etc/ppp.devices\fP or on the \fIpppd\fP command line.
X.TP
X.B local:remote
XThe address of this machine, optionally followed by the expected
Xaddress for the the remote machine.  Can be specified either as
Xsymbolic names (if the IP addresses are known locally) or as literal
XIP addresses.
X.SP
XBoth addresses must be specified when running as a daemon in
X`autocall' mode.  If only `local:' is specified when receiving an
Xincoming call, the remote address will be discovered during IPCP
XIP-Addresses negotiations.
X.TP
X.B auto
XStart in `autocall' mode and detach from the controlling terminal to
Xrun as a daemon.  Initiate a connection in response to a packet
Xspecified in the `bringup' category in filter-file.  Requires both
Xlocal and remote addresses.
X.TP
X.B up
XIf used with \fBauto\fP, bring the link up immediately rather than
Xwaiting for traffic.
X.TP
X.B nodetach
XDon't detach from the controlling terminal in `autocall' mode.
X.TP
X.B active
XBegin in the LCP Active-Open state (the default unless in
X`autocall' mode).
X.TP
X.B passive
XBegin in the LCP Passive-Open state (the default in `autocall' mode).
X.TP
X.B old
XEnable backward compatibility with older implementations of PPP by
Xusing 0x0037 (as specified in the typographical error in RFC1172
Xsection 5.2) to negotiate VJ TCP Header Compression in IPCP.
X.TP
X.B log\ \fRlog-file\fP
XDirect logging messages to log-file (default: 
X.BR /usr/adm/pppd.log ).
X.\" unimplemented - BS 910803
X.\" .TP
X.\" .B nolog
X.\" Produce no log file.  This is dangerous.
X.TP
X.B filter\ \fRfilter-file\fP
XLook in filter-file for packet filtering and link management
Xinformation (default: 
X.BR /etc/ppp.filter ).
X.TP
X.B idle\ \fRidle-time\fP
XIf in `autocall' mode, turn off the link when idle-time seconds pass
Xwithout passing a packet specified in the `keepup' category in
Xfilter-file (default: never).
X.TP
X.B timeout\ \fRrestart-time\fP
XSet the LCP and IPCP option negotiation restart timer (default 3 seconds).
X.TP
X.B debug\ \fRdebug-level\fP
XSet the debugging verbosity to debug-level (default 0).
X.\" unimplemented - BS 910803
X.\" .TP
X.\" .B requireupap
X.\" Require UPAP authentication.
X.\" .TP
X.\" .B noupap
X.\" Don't allow UPAP authentication (the default).
X.SH SIGNALS
XUpon reception of the following signals,
X.I pppd\^
Xtakes the indicated actions:
X.TP "\w'SIGTERM\ \ \ \ \ 'u"
X.B SIGINT
XDisconnect gracefully from an active session.  If in `autocall' mode,
Xre-read the filter file and reset the call retry delay timer and call
Xretry backoff interval.  Exit if not in `autocall' mode.
X.TP
X.B SIGHUP
XDisconnect abruptly from an active session.  If in `autocall' mode,
Xre-read the filter file.  Exit if not in `autocall' mode.
X.TP
X.B SIGTERM
XDisconnect gracefully from an active session, then exit.
X.TP
X.B SIGUSR1
XRe-read the filter file, and increment the verbosity level for
Xdebugging information written to the log file:
X.RS
X.TP "\w'3\ \ \ 'u"
X1
XDial chat
X.TP
X2
XAll IP messages
X.TP
X3
XInterface changes, etc.
X.TP
X4
XLCP, IPCP, UPAP and other finite state machine messages
X.TP
X5
XMore detailed procedure call messages
X.TP
X6
XAll PPP messages (without framing)
X.TP
X7
XTimers, even more detailed procedure call messages
X.TP
X8
XCharacters read or written
X.RE
X.TP
X.B SIGUSR2
XRe-read the filter file, and reset the debugging verbosity level to 0
X(the default).
X.SH EXAMPLE
X.PP
XTo run a pair of daemons on `oursystem', one maintaining a constant
Xlink with `backbonesystem' and the other prepared to initiate outbound
Xcalls to a neighboring machine named `theirsystem', add the following
Xto \fB/etc/rc.local\fP:
X.RS
X.nf
X.ta \w''u \w'if\ [\ -f\ 'u \w'if\ [\ -f\ if\ [\ -f\ 'u \w'if\ [\ -f\ if\ [\ -f\ system:t'u
X#
Xif [ -f /usr/etc/pppd ]; then
X	if [ -f /usr/adm/pppd.log ]; then
X		mv /usr/adm/pppd.log /usr/adm/OLDpppd.log
X	fi
X	pppd oursystem:backbonesystem auto up
X			(echo -n ' pppd(backbonesystem)') > /dev/console
X	pppd oursystem:theirsystem auto idle 120
X			(echo -n ' pppd(theirsystem)') > /dev/console
Xfi
X.fi
X.RE
X.PP
XTo allow a PPP implementation running on `theirsystem' to dial into
X`oursystem', insert the following into /etc/passwd on `oursystem':
X.RS
X.nf
X.RS
XTheirPPP:??:105:20:Their System's PPP:/tmp:/usr/etc/ppplogin
X.RE
X.fi
X.RE
Xwhere 
X.B /usr/etc/ppplogin
Xis an executable shell script that looks something like
X.PP
X.RS
X.nf
X#!/bin/sh
X#
XPATH=/usr/bin:/usr/etc
X#
Xmesg n
Xstty -tostop
Xexec pppd `hostname`:theirsystem idle 130
X.PP
X.fi
X.RE
X.SH RECOMMENDATIONS
X.PP
XUse host names in
X.B /etc/rc.local
Xif they are known locally.  If a call would be required to resolve a
Xhost name, use its literal IP address instead.
X.SH SEE ALSO
Xtun(4),
Xppp.devices(5), 
Xppp.dialers(5),
Xppp.filter(5),
Xppp.systems(5),
X.\" pppd(8), 
XRFC1171, 
XRFC1172, 
XRFC1144.
X.SH CREDITS
XParts of the protocol engine were written by Drew D. Perkins,
Xddp@andrew.cmu.edu, now ddp@interstream.com.
X.SH COPYRIGHT INFORMATION
XThis daemon contains code that is Copyright \(co 1989 Carnegie Mellon
XUniversity.
X.PP
XCopyright \(co 1991 Morning Star Technologies Inc., all rights
Xreserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 pppd.8"
X.\" End:
END_OF_FILE
if test 8053 -ne `wc -c <'ppp/man/pppd.8'`; then
    echo shar: \"'ppp/man/pppd.8'\" unpacked with wrong size!
fi
# end of 'ppp/man/pppd.8'
fi
if test -f 'ppp/man/ppp.filter.5' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/ppp.filter.5'\"
else
echo shar: Extracting \"'ppp/man/ppp.filter.5'\" \(8895 characters\)
sed "s/^X//" >'ppp/man/ppp.filter.5' <<'END_OF_FILE'
X.\" @(#)ppp.filter.5	1.6
X.de SP
X.br
X.if t .sp .5v
X.if n .sp 1v
X..
X.TH PPP.FILTER 5 "2 August 1991" "Morning Star PPP 1.0 Beta" "Morning Star Technologies"
X.SH NAME
Xppp.filter \- PPP packet filter specification file format
X.SH DESCRIPTION
XThis file describes how on-demand PPP links are to be maintained.
XNormally, any packet causes the link to be brought up to its
Xdestination; any packet is allowed to traverse the link; and any
Xpacket is sufficient to keep the idle timer from causing the link to
Xbe shut down.  This is rarely appropriate behavior, so the filter file
Xallows individual selectivity based on the type of the packet and its
Xsource or destination.  These selection criteria may be specified for
Xany of the three phases of operation:  bringing up the link, passing
Xpackets on the link, and shutting down the link because of inactivity.
XPacket logging detail may also be selected using the same criteria.
X.SH FORMAT
XComments begin with a `#' and extend to the end of the line;
Xblank lines, or lines beginning with a `#', are ignored.
XUpper/lower case distinctions are ignored in hostname specifications, but
Xare significant elsewhere.
XFields on a line are separated by horizontal white space (blanks or tabs).
X.PP
XIf a line begins with a hostname or IP address or the special word
X`default', that line is considered to be the beginning of a new set of
Xfiltering specifications.  If a newline is followed by white space,
Xthat line is a continuation of the filtering specification already in
Xprogress.
X.PP
XThere are four keywords to describe the actions taken by
X.I pppd\^
Xin response to a particular packet:
X.RS
X.TP "\w'bringup\ \ \ 'u"
Xbringup
XDescribes those packets that will cause a call to be placed and a
Xconnection initiated.  If a packet would not be passed, it will also
Xnot cause the link to be brought up.
X.TP
Xpass
XDescribes those packets that will be allowed to traverse the link once
Xit is established.  If a packet would not be passed, it will also not
Xcause the link to be brought up.  Any packet that is not passed is
Xoptionally logged, then discarded.
X.TP
Xkeepup
XDescribes those packets that will keep the idle timer from expiring.
X.TP
Xlog
XDescribes those packets to be noted in the log file.
X.RE
X.PP
XAfter the action keywords come words, separated by white space,
Xdescribing packets that fit the criteria for that action.  Each list
Xof words is processed in the order they are found in the file.  As
Xsoon as a pattern or a condition is found that matches the packet in
Xquestion,
X.I pppd
Xtakes the indicated action and ignores the rest of the list.  
X.PP
XWords may be names or numbers describing entries in
X.BR /etc/services ,
Xor names or IP addresses of hosts or networks, or the special keyword
X`all', which is the default for all actions except `log', where the
Xdefault is `!all'.  If a network is specified, either by name or by
Xaddress, then the corresponding subnet mask must also be specified if
Xit is of a different size than the default for that class of network.
XQualifications within a word are separated by slashes (`/').  The
Xsense of each word may be individually negated by prefixing its string
Xwith an exclamation mark (`!').
X.PP
XIn the `log' filter specification, the special keyword `trace' causes
Xthe contents of the indicated type of packet to be written to the log
Xfile.
X.PP
XSince TCP data streams are opened when the initiator sends a SYN
Xpacket to the intended recipient,
X.I pppd
Xcan discern between outbound (sent from this host) and inbound (coming
Xfrom the other end of the link) uses of TCP applications such as
Xtelnet or FTP.  The special keyword `syn' allows filtering or logging
Xthese session starters. Qualifying it with `recv' or `send' allows
Xsessions to be started or logged only if they are initiated in the
Xindicated direction.
X.SH EXAMPLE
X.PP
XThe following
X.B /etc/ppp.filter
Xfile describes the default behavior of
X.IR pppd\^ ,
Xeither in the absence of a filter specification file or in the case of
Xan empty file:
X.PP
X.RS
X.nf
X.ta \w''u \w'backbone\ \ \ 'u \w'backbone\ \ \ bringup\ \ \ 'u
X#
X#	/etc/ppp.filter - PPP configuration file binding packet
X#			  types to actions.
X#	Describes the default behavior of the daemon
X#
Xdefault	bringup all pass all keepup all log !all
X#
X.fi
X.RE
X.PP
XIf any action is unspecified in the filter file, the default is no
Xrestrictions of that sort and no packet logging.
X.PP
XThe following
X.B /etc/ppp.filter
Xfile instructs the daemon that a connection to any neighbor except the
Xhost `backbone' be brought up in response to any packet except for
Xthose generated by NTP, ICMP Destination Unreachable, and
X.IR rwhod\^ .
XIf those are the only types of packets flowing across the link, it
Xwill not be kept up, but all packets are allowed to cross the link
Xwhile it is up.
X.PP
XIn the special case of the host `backbone' (perhaps a server belonging
Xto a network connectivity vendor), only telnet and FTP sessions, SMTP
Xelectronic mail, NNTP network news, and domain name service queries
Xare considered sufficient cause to bring the link up or to keep it up
Xif otherwise idle.
X.SP
XOnce the link is up, all the above plus NTP clock chimes and ICMP
Xmessages may flow across the link.  No packets to or from a particular
Xhost, nor any packets except domain name service queries and responses
Xfor any host on subnet 42 of the class B network 137.175, are ever
Xallowed to cross the link, nor do they cause the link to be initiated.
XWe allow telnet and FTP sessions only if they are initiated in the
Xoutbound direction.
X.SP
XWe log occurrences of various ICMP problem messages (Unreachable, Time
XExceeded, and IP header problems), including the complete contents of
Xthe latter reports.  We log all telnet and FTP sessions, including
Xinbound attempts (though they will fail because they are excluded in
Xthe `pass' specification above).  We also log the first packet of any
Xelectronic mail message flowing over this link on its way to or from a
Xparticular host.
X.PP
X.RS
X.nf
X.ta \w''u \w'backbone\ \ \ 'u \w'backbone\ \ \ bringup\ \ \ 'u
X#
X#	/etc/ppp.filter - PPP configuration file binding packet
X#			  types to actions.
X#
Xbackbone	bringup	smtp nntp 53/udp 53/tcp telnet ftp !all
X	pass	!131.119.250.104
X		53/udp/137.175.42.0/255.255.255.0
X		53/tcp/137.175.42.0/255.255.255.0
X		!137.175.42.0/0xffffff00
X		53/udp 53/tcp 
X		!telnet/syn/recv !ftp/syn/recv
X		smtp nntp ntp icmp telnet ftp
X		!all
X	keepup	smtp nntp 53/udp 53/tcp telnet ftp !all
X	log	3/icmp 11/icmp 12/icmp/trace
X		telnet/syn ftp/syn
X		smtp/syn/terminus.netsys.com
X#
Xdefault	bringup	!ntp !3/icmp !who
X	keepup	!ntp !3/icmp !who
X#
X.fi
X.RE
X.SH RECOMMENDATIONS
X.PP
XSimpler filter specifications allow
X.I pppd
Xto start up quicker and run faster, with less processing overhead for
Xeach packet, and are more likely to be gotten right.  The silly
X`backbone' example above is severe overkill for the sake of
Xillustration, and evolved over a period of several weeks.  It took the
Xauthors several tries to get it right.  Start with a simple filter
Xspecification and add each special case only as the need presents
Xitself.  Then test carefully to ensure that your change had only the
Xdesired effect.
X.PP
XBe very careful with traffic logging and even more careful with packet
Xcontent tracing.  Make the selection criteria very narrow, or the log
Xfile will grow extremely large in a short period of time.  Also, if
Xthe daemon is running on a diskless workstation or if the log file is
Xon a NFS-mounted file system, increased amounts of logging information
Xwill drastically impede the daemon's ability to process packets.
XRemember, NFS write(2)s are synchronous.
X.PP
XIf you specify host names, be sure that their addresses are available
Xlocally, even with the connection down.  If you find that you must
Xbring up a connection to resolve a domain name, consider using that
Xhost's IP address (decimal numbers separated by periods) in both
X.B /etc/ppp.filter
Xand
X.B /etc/ppp.systems
Xinstead.
X.PP
XIf you want to specify all Domain Name Service traffic, use both
X53/tcp and 53/udp instead of saying `domain'.  Some DNS traffic uses
Xeach transport, and simply saying `domain' would be ambiguous.
XSimilarly, some systems' older \fB/etc/services\fP files, as
Xdistributed by the manufacturer, list NTP as a TCP service.  When the
Xcurrent UDP NTP implementation was installed on your system, the
Xadministrator may have left the old 123/tcp entry along with the
Xcorrect 123/udp.  The correct solution is to remove the 123/tcp entry
Xfrom \fB/etc/services\fP.  A workaround would be to specify 123/udp in
X\fB/etc/ppp.filter\fP\^.
X.SH SEE ALSO
Xtun(4),
Xppp.devices(5),
Xppp.dialers(5),
X.\" ppp.filter(5),
Xppp.systems(5),
Xservices(5),
Xpppd(8),
XRFC792,
XRFC1171,
XRFC1172,
XRFC1144.
X.SH COPYRIGHT INFORMATION
XCopyright \(co 1991 Morning Star Technologies Inc.; all
Xrights reserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 ppp.filter.5"
X.\" End:
END_OF_FILE
if test 8895 -ne `wc -c <'ppp/man/ppp.filter.5'`; then
    echo shar: \"'ppp/man/ppp.filter.5'\" unpacked with wrong size!
fi
# end of 'ppp/man/ppp.filter.5'
fi
if test -f 'ppp/man/ppp.dialers.5' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/ppp.dialers.5'\"
else
echo shar: Extracting \"'ppp/man/ppp.dialers.5'\" \(4384 characters\)
sed "s/^X//" >'ppp/man/ppp.dialers.5' <<'END_OF_FILE'
X.\" @(#)ppp.dialers.5	1.3
X.TH PPP.DIALERS 5 "25 July 1991" "Morning Star PPP 1.0 Beta" "Morning Star Technologies"
X.SH NAME
Xppp.dialers \- PPP dialer description file format
X.SH DESCRIPTION
XThe file
X.B /etc/ppp.dialers
Xdescribes how to dial each type of modem attached to the UNIX\*R system
Xthat is to be made available for for outbound PPP calls.  It is
Xexamined when
X.I pppd\^
Xneeds to originate a call to a neighboring machine.
X.PP
XWhen
X.I pppd\^
Xselects a line from
X.BR /etc/ppp.systems ,
Xit uses the `speed' field to select an entry in
X.BR /etc/ppp.devices ,
Xfrom which it uses the `dialer' field to select an entry in
X.BR /etc/ppp.dialers .
X.I Pppd\^
Xthen interprets the `chat script' field from that dialer description.
X.SH FORMAT
XEntries are one to a line; blank lines are ignored.
XComments begin with a `#' and extend to the end of the line.
XUpper/lower case distinctions in the dialer field are significant for
Xmatching purposes, as are strings in the chat script.
XFields on a line are separated by horizontal white space (blanks or
Xtabs).
X.PP
XEach entry must contain two fields, in this order:
X.TP "\w'chat script\ \ \ 'u"
Xdialer
XThe name of this dialer, to be matched against the dialer field in
X.B /etc/ppp.devices
X.TP
Xchat script
XA description of the conversation that
X.I pppd\^
Xholds with the modem.  It takes the form of a word to expect the
X`remote' end to send, followed by a word to send in response.  After
Xeach `send' string that doesn't end with \fB\\c\fP,
X.I pppd\^
Xsends a carriage return character (ASCII 0x0d).
X.SH CHAT SCRIPT PARTICULARS
X.PP
XCertain special words may be used in the chat script to control the
Xbehavior of
X.I pppd\^
Xas it attempts to dial.  
X.RS
X.TP "\w'TIMEOUT \fItimeout-time\fP\ \ \ 'u"
XABORT \fIabort-string\fP
XIf
X.I pppd\^
Xsees \fIabort-string\fP while executing the remainder of the chat
Xscript, abort the dialing attempt and note the failure in the log
Xfile.
X.TP
XTIMEOUT \fItimeout-time\fP
XWhile executing the current chat script, wait \fItimeout-time\fP
Xseconds for a response before considering the dialing attempt to have
Xtimed out.
X.RE
X.PP
XThe expect-send couplet of \fB"" WORD\fP sets the line parity
Xaccordingly:
X.RS
X.TP "\w'P_EVEN\ \ \ 'u"
XP_ZERO
XSet the parity bit to zero.
X.TP
XP_ONE
XSet the parity bit to one.
X.TP
XP_EVEN
XTransmit characters with even parity.  This is the default.
X.TP
XP_ODD
XTransmit characters with odd parity.
X.RE
X.PP
XIn the midst of either an `expect' string or a `send' string,
X\fB^\fP\fIx\^\fP gets translated into the appropriate control
Xcharacter, and \fB\\\fP\fIx\^\fP gets translated into \fIx\^\fP.
XOther special sequences are:
X.RS
X.TP "\w'\\T\ \ \ \ 'u"
X\\s
XSend or receive a space character (ASCII 0x20)
X.TP
X\\t
XSend or receive a horizontal tab character (ASCII 0x09)
X.TP
X\\n
XSend or receive a linefeed character (ASCII 0x0a)
X.TP
X\\r
XSend or receive a carriage return character (ASCII 0x0d)
X.TP
X\\c
XDon't append a carriage return character after sending this string (send only)
X.TP
X\\d
XDelay for two seconds before proceeding (send only)
X.TP
X\\q
XDon't print succeeding send strings (e.g. for a password)
Xin any debugging output.  Subsequent \fB\\q\fP sequences toggle `quiet' mode.
X.TP
X\\T
XInsert the telephone number (found in the fifth field of
X.BR /etc/ppp.systems )
Xhere
X.RE
X.SH EXAMPLE
XBecause of the restrictions of physical media, the following example
Xmay represent single lines from
X.B /etc/ppp.dialers
Xon multiple lines of your output medium.  In the actual file itself,
Xeach entry must be contained on a single line, each of which may
Xcontain up to 1023 characters.
X.PP
X.RS
X.nf
X.ta \w'TB-V32\ \ 'u
X#
X#	/etc/ppp.dialers - PPP dialers file
X#
X#Dialer	Chat script
XTB-PEP	ABORT NO\\sCARRIER ABORT BUSY TIMEOUT 5
X	"" AT OK-AT-OK ATZ OK \\c TIMEOUT 60 ""
X	ATX1S50=255S111=0S58=2DT\\T CONNECT\\sFAST
XTB	ABORT NO\\sCARRIER ABORT BUSY TIMEOUT 5
X	"" AT OK-AT-OK ATZ OK \\c TIMEOUT 30 ""
X	ATX1S111=0S58=2DT\\T CONNECT \\c \\n
XTB-V32	ABORT NO\\sCARRIER ABORT BUSY TIMEOUT 5
X	"" AT OK-AT-OK ATZ OK \\c TIMEOUT 30 ""
X	ATX1S111=0S58=2DT\\T CONNECT \\c \\n
X.fi
X.RE
X.SH SEE ALSO
Xtun(4), 
Xppp.devices(5), 
X.\" ppp.dialers(5),
Xppp.filter(5),
Xppp.systems(5),
Xpppd(8), 
XRFC1171, 
XRFC1172, 
XRFC1144.
X.SH COPYRIGHT INFORMATION
XCopyright \(co 1991 Morning Star Technologies Inc.; all
Xrights reserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 ppp.dialers.5"
X.\" End:
END_OF_FILE
if test 4384 -ne `wc -c <'ppp/man/ppp.dialers.5'`; then
    echo shar: \"'ppp/man/ppp.dialers.5'\" unpacked with wrong size!
fi
# end of 'ppp/man/ppp.dialers.5'
fi
if test -f 'ppp/man/tun.4' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/tun.4'\"
else
echo shar: Extracting \"'ppp/man/tun.4'\" \(5681 characters\)
sed "s/^X//" >'ppp/man/tun.4' <<'END_OF_FILE'
X.\" @(#)tun.4	1.2
X.TH TUN 4 "3 August 1991" "Morning Star IP Tunnel" "Morning Star Technologies"
X.SH NAME
Xtun \- IP network tunnel driver
X.SH CONFIG
Xpseudo-device tun[\fIn\fP\^]
X.SH SYNOPSIS
X.nf
X.ft B
X#include <sys/tun.h>
Xopen("/dev/tun\fIn\fP\^", mode);
X.ft P
X.fi
X.SH DESCRIPTION
X.LP
XWhen IP packets are written to \fB/dev/tun\fIn\fR\^, they will be
Xreceived by the kernel's IP layer on the network interface
X\fBtun\fIn\fR.  When the kernel's IP layer sends packets to the IP
Xinterface \fBtun\fIn\fR, they will be available for reading on
X\fB/dev/tun\fIn\fR\^.
X.LP
XInstead of having hardware and an associated kernel interface that
Xsupport network functions, the \fBtun\fP driver allows a network
Xinterface to be implemented as a user-space process.  While talking to
Xthe same set of tunnel drivers on the same system, different network
Xinterface processes can implement different IP encapsulation methods,
Xsuch as RFC877 for use over CCITT X.25-based public data networks, or
XRFC1171 PPP for use over dedicated lines and dialup modems.
X.LP
XThe \fBtun\fP driver provides support for a pair of devices
Xcollectively known as an \fIIP tunnel\fP\^.  The two devices
Xcomprising a tunnel are known as the \fIinbound\fP and \fIoutbound
Xsides\fP, similar to the pairing between \fB/dev/tty\fIn\fR (the
Xinbound terminal) and \fB/dev/cu\fIn\fR (the outbound `auto-call unit'
Xavailable on many systems).  
XThe outbound side's minor device number is that of the inbound side
Xplus 128, though they together appear to IP as one interface.
XIf both the inbound and outbound sides of a tunnel device are open,
Xpackets received from IP are delivered to only the inbound side.
X.LP
XIf a TCP packet received from IP
Xis part of a telnet, rlogin, or FTP command stream, it
Xwill be put in a \fIfast queue\fP\^.  All packets in the fast queue
Xare delivered to the user before any packets in the normal queue.
X.SH IOCTLS
XA few special \fBioctl\fPs are provided, to supply the functionality
Xneeded by applications programs to emulate real hardware interfaces.
XThe complete list of supported \fBioctl\fPs is:
X.TP \w'SIOCSIFFLAGS\ 'u
X.SB SIOCSIFADDR
XSets the interface address.
X.TP
X.SB SIOCSIFFLAGS
XAllows changing all the usual \fBif\fP flags, as well as
X.RS
X.TP \w'IFF_POINTOPOINT\ 'u
X.SB IFF_POINTOPOINT
XConfigure this interface as one end of a point-to-point network.
X.TP
X.SB IFF_BROADCAST
XConfigure this interface for a broadcast-capable network.
X.RE
X.TP
X.SB SIOCGIFMTU
XReturns the Maximum Transmission Unit (in octets) for a packet sent
Xover this interface.
X.TP
X.SB SIOCSIFMTU
XSets the Maxumum Transmission Unit (in octets) for a packet sent over
Xthis interface.  Larger packets will be sent in fragments.
X.\"
X.\" This isn't implemented yet.
X.\"
X.\" .TP
X.\" .SB TUIOGSTATS
X.\" Returns a structure filled with tunnel driver traffic statistics:
X.\" .nf
X.\" .ft B
X.\" .ta \w''u \w'stru'u \w'structsigned\ int\ tu_ipackets\ \ \ \ \ 'u
X.\" struct tunstat
X.\" 	{
X.\" 	unsigned int tu_ibytes;	/* total number of data bytes in */
X.\" 	unsigned int tu_ipackets;	/* total number of data packets in */
X.\" 	unsigned int tu_ierrors;	/* total number of input errors */
X.\" 	unsigned int tu_obytes;	/* total number of data bytes out */
X.\" 	unsigned int tu_opackets;	/* total number of data packets out */
X.\" 	unsigned int tu_oerrors;	/* total number of output errors */
X.\" 	};
X.\" .ft P
X.\" .fi
X.TP
X.SB TUIOSADRMD
XSet or clear `address mode', in which packets read are prefaced with
Xfour octets containing the destination IP address in network byte
Xorder.
XThe third argument is a pointer to an integer containing either a zero
Xor a one, indicating whether `address mode' should be cleared or set,
Xrespectively.
XIf both `address mode' and `packed puffer mode' are set, each packet's
Xdestination address will come first, followed by the packet's length,
Xfollowed by the packet itself.
X.TP
X.SB TUIOGADRMD
XGet the current status of `address mode'.
X.TP
X.SB TUIOSPKBMD
XSet or clear `packed buffer mode' where multiple packets are encoded
Xin single read/write buffers.
XThe third argument is a pointer to an integer containing either a zero
Xor a one, indicating whether `packed buffer mode' should be cleared or
Xset, respectively.
XIf set, each packet is preceded by two octets representing the next
Xpacket's length in octets.  If cleared, packets will be delivered one
Xper read(3) from the tunnel device.
XIf both `address mode' and `packed puffer mode' are set, each packet's
Xdestination address will come first, followed by the packet's length,
Xfollowed by the packet itself.
X.TP
X.SB TUIOGPKBMD
XGet the current status of `packed buffer mode'.
X.TP
X.SB TUIOSNAME
XSet the interface name (may only be invoked by the superuser).
X.TP
X.SB TUIOGNAME
XGet the interface name.
X.TP
X.SB FIONBIO
XSet or clear non-blocking mode for I/O operations.
X.SH EXAMPLES
X.nf
X.RS
X#include <sys/tun.h>
Xint tun_fd = -1, len;
Xchar *packet;
X
Xtun_fd = open("/dev/tun0", O_RDWR);
Xioctl(tun_fd, TUIOSNAME, "du");
Xlen = read(tun_fd, packet, size);
Xwrite(tun_fd, packet, len);
X.RE
X.fi
X.SH ERRORS
X.LP
XIf a packet is delivered to the interface for an address family other
Xthan AF_INET, EAFNOSUPPORT will be returned.
X.SH FILES
X.PD 0
X.TP 30
X\fB/dev/tun0\fP\^ through \fB/dev/tun127\fP
X`inbound' tunnel devices
X.TP
X\fB/dev/tun128\fP\^ through \fB/dev/tun255\fP
X`outbound' tunnel devices
X.PD
X.SH "SEE ALSO"
X.\" tun(4), 
Xif(4n),
Xppp.devices(5), 
Xppp.dialers(5),
Xppp.filter(5),
Xppp.systems(5),
Xpppd(8), 
XRFC1171, 
XRFC1172, 
XRFC1144,
Xx25-ddn(7),
Xx25d(8),
XRFC877.
X.SH COPYRIGHT INFORMATION
XCopyright \(co 1991 Morning Star Technologies Inc.; all rights
Xreserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -man -TX75 tun.4"
X.\" End:
END_OF_FILE
if test 5681 -ne `wc -c <'ppp/man/tun.4'`; then
    echo shar: \"'ppp/man/tun.4'\" unpacked with wrong size!
fi
# end of 'ppp/man/tun.4'
fi
if test -f 'ppp/man/test.ms' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/man/test.ms'\"
else
echo shar: Extracting \"'ppp/man/test.ms'\" \(37207 characters\)
sed "s/^X//" >'ppp/man/test.ms' <<'END_OF_FILE'
X.\" @(#)intro.ms	1.6
X.\"
X.\" Pass me through tbl before handing me to troff with the -ms macro set
X.\" See README.fonts if things look wrong.
X.\"
X.\" Still to write:
X.\"	example crontab entry to clean up logfiles (like syslog.*)
X.\"	more and better hints and kinks about ppp.* configurations
X.\"	address and subnet assignment and routing strategies
X.\"	use for netmask argument
X.\"	NeXT configuration suggestions
X.\"	interoperability suggestions with NetBlazer & FTP Software
X.\"	more specific rc suggestions
X.\"	everything that new_state() does to the argv
X.\"	when the daemon supports it: UPAP and other authorization stuff
X.\"	ppp.auth(5)
X.\"
X.nr PO .5i
X.nr PS 12
X.nr VS 14
X.fp 4 CR
X.de SP
X.br
X.if t .sp .5v
X.if n .sp 1v
X..
X.de D1
X.if t .sp .5
X.if n .sp 1
X.RS
X.nf
X..
X.de D2
X.fi
X.RE
X.if t .sp .5
X.if n .sp 1
X..
X.ds CO (c)
X.if \w'\\(co'>0 .ds CO \\(co
X.\"
X.\"	N3 (good name, eh?) needs to be defined twice, else it doesn't
X.\"	work.  I don't know why.
X.\"
X.ds N3 \\uTM\\d
X.ds N3 \\uTM\\d
X.if t .ds N3 \\u\\s-2TM\\s+2\\d
X.LP
X\0
X.sp 2i
X.ND
X.ds CH
X.CD
X.ps \\n(PS+\\n(PS
XMorning Star PPP
X.NL
X
XVersion 1.0\(*b
X
X.ps \\n(PS+\\n(PS
X
XUser Guide
X
X.NL
XRevision 1.6
XJuly 31, 1991
X.DE
X.bp
X.LP
X\0
X.sp 2i
X.CD
X.SM
XCopyright \*(CO 1991 Morning Star Technologies, Inc.
XAll rights reserved
X
XPublished by
XMorning Star Technologies, Inc.
X1760 Zollinger Road
XColumbus, Ohio  43221
XUSA
X
X+1 614 451 1883 (voice)
X+1 800 558 7827 (voice)
X+1 614 459 5054 (FAX)
Xppp-beta@morningstar.com (e-mail)
X.NL
X.DE
X.bp
X.nr % 1
X.ds CF - % -
X.CD
X.B
XMorning Star PPP
X(Version 1.0\(*b\^)
XUser Guide (version 1.6)
X.R
X.DE
X.LP
X.ds CH \fBMorning Star PPP (Version 1.0\(*b\^) User Guide (version 1.6)\fP
X.NH 1
XIntroduction to PPP
X.LP
XMorning Star PPP provides an easy and flexible means of creating
Xwide-area TCP/IP based networks to transfer data between UNIX\**
X.FS
XUNIX is a registered trademark of AT&T.
X.FE
Xsystems, and between UNIX systems and others that also implement the
XInternet standard Point to Point Protocol.  Users of Morning Star PPP
Xcan connect their isolated UNIX systems to established TCP/IP
Xnetworks, or can connect geographically-separated networks.  Morning
XStar PPP can also run on a hub machine to provide dialin access to
Xmultiple remote systems.
X.LP
XSince they continue to use the UNIX host's native TCP/IP
Ximplementation and related utilities, users require no additional
Xtraining to make full use of the new link.  In fact, because of the
Xtransparency of TCP/IP internetwork routing, many may be unaware that
Xremote facilities are not connected to the local network.
X.LP
XBy contrast to network routers that requires an expensive leased line
Xto provide a constant connection, Morning Star PPP can establish the
Xlink when traffic demand warrants a call over standard telephone
Xlines.
XWhen the traffic has finished, Morning Star PPP will hang up the
Xconnection to save on telephone costs.
X.LP
XThe UNIX system administrator has complete control over the traffic
Xallowed to traverse the link.  Morning Star PPP can even turn a UNIX
Xsystem into a selective-isolation `firewall' gateway, enahancing the
Xsecurity provided to other systems on the local network.
X.LP
XMorning Star PPP implements HDLC address/control field and protocol
Xfield compression, as well as TCP header compression, to reduce
Xtransmission overhead to a minimum.  This improves both throughput and
Xinteractive response on typical modem connections.  Its interface to
Xthe UNIX host's TCP/IP implements Van Jacobson's TCP `fast queue'
Xscheme, whereby interactive packets are given priority for
Xtransmission on a congested link.
X.NH 1
XUsing this Manual
X.LP
XThe portions of this manual following this introductory User Guide
Xhave been organized in the style of the standard Berkeley UNIX manual
Xpages.  
X.\" User commands are described in Section 1.
X.\" The interface to the host UNIX system's IP implementation is
X.\" described in Section 4.
XSection 5 describes the format of the configuration files.  The
XMorning Star PPP daemon itself is described in Section 8.
X.NH 1
XRelated Manuals
X.LP
XThe Morning Star PPP daemon is described in detail in the UNIX-style
Xmanual page \fBpppd\fP\^(8).  Its configuration files are described in
X\fBppp.devices\fP\^(5), \fBppp.dialers\fP\^(5), \fBppp.filter\fP\^(5),
Xand \fBppp.systems\fP\^(5).
XThe IP tunnel driver is described in \fBtun\fP\^(4).
X.LP
XHardware installation, when necessary, is described in the \fIHardware
XInstallation Guide\fP\^ for the Morning Star \fISnapLink\fP\^\** 
X.FS
XSnapLink is a registered trademark of Morning Star Technologies, Inc.
X.FE
XSCSI communications interface.  Not all Morning Star PPP installations
Xrequire additional hardware, so if you are using a serial port-only
Xproduct, you won't have received a copy of any \fIHardware
XInstallation Guide\fP\^.
X.LP
XThe authoritative references on TCP/IP and the Point-to-Point Protocol
Xare the Internet Requests for Comments series, particularly RFCs
X1171\**
X.FS
XPerkins, D., `Point-to-Point Protocol for the transmission of
Xmulti-protocol datagrams over Point-to-Point links', RFC 1171, Carnegie
XMellon University, July 1990.
X.FE
Xand
X1172\**.
X.FS
XPerkins, D. and Hobby, R., `The Point-to-Point Protocol (PPP) Initial
XConfiguration Options', RFC 1172, Carnegie Mellon University and the
XUniversity of California at Davis, July 1990.
X.FE
XThese are occasionally updated by the Point-to-Point Protocol Working
XGroup of the Internet Engineering Task Force (IETF), and are available
Xfrom the Network Information Center.  See the file \fBrfc-index\fP in
Xthe Morning Star PPP distribution directory for instructions on
Xacquiring an up-to-date copy.
X.LP
XTCP header compression is described in RFC 1144\**,
X.FS
XJacobson, V., `Compressing TCP/IP Headers for Low-Speed Serial Links',
XRFC 1144, Lawrence Berkeley Laboratory, February 1990.
X.FE
Xand reduces the number of protocol overhead bytes required for typical
Xpackets in a TCP data connection.
X.LP
XFast queueing for interactive TCP packets is described by its
Ximplementation in Van Jacobson's header-compressed SLIP\**.
X.FS
XJacobson, V., ftp.ee.lbl.gov:cslipbeta.tar.Z, if_sl.c, UTSL.
X.FE
X.NH 1
XSample Configuration
X.LP
XWe'll go through the steps necessary to configure a simple but
Xillustrative installation.  Our system, \fIrobin\fP\^, has a
XTelebit\**
X.FS
XTelebit is a trademark of Telebit Corporation.
X.FE
XT1600 asynchronous dialup modem on its /dev/ttya, which it uses for
Xits on-demand connection to \fIlark\fP\^.  It is also connected to an
Xadjacent machine, \fIsparrow\fP\^, via a short null-modem cable on its
X/dev/ttyb, which it uses for a connection that is constantly active.
X.NH 2
XUnpacking the distribution
X.LP
XYou received the software distribution as a \fBcompress\fP\^(1)ed
X\fBtar\fP\^(1) archive.  Create a working directory and unpack it:
X.D1
X.ft 4
X% ls mstppp*
Xmstppp.tar.Z
X% mkdir /usr/local/src/ppp
X% cp mstppp.tar.Z /usr/local/src/ppp
X% cd /usr/local/src
X% zcat ppp/mstppp.tar.Z | tar xvf -
X\fI...lots of output...\fR
X%
X.ft P
X.D2
X.NH 2
XInstalling the software and documentation
X.LP
XBecome the superuser, and run the installation shell script:
X.D1
X.ft 4
X% su
XPassword: \fI(enter your \fBroot\fP password here)\f4
X# cd ppp
X# ./Install
X.ft P
X.D2
X.LP
XIf necessary, the \fBInstall\fP script will ask you questions about
Xyour system.  It will place the daemon into \fB/usr/etc/pppd\fP and
Xput the manual pages into the appropriate locations.  It will create a
Xshell script named \fBx25.uninstall\fP, to be used in case you need to
Xremove the software from your system.
X.NH 2
XBuilding and installing a kernel
X.LP
XThe contents of the file /usr/local/src/ppp/README will describe how
Xto configure and build a new kernel, move it into place, and reboot
Xyour system to ensure that it runs correctly.  If your system supports
Xdynamically loadable device drivers, you may need only to reboot for
Xthem to become available.
X.LP
XThe README file also describes how to configure the asynchronous
Xterminal interfaces on your machine, if any special arrangements are
Xnecessary.
X.NH 2
XArranging for PPP connections
X.LP
XOne tunnel driver must be installed in the kernel for each remote host
Xwith which we will establish a link, no matter which end of the link
Xinitiates the connection and no matter how many simultaneous links
Xwill be in operation.  To make configuration easier, if you say
X`pseudo-device tun' in the kernel configuration file, it will be the
Xsame as saying `pseudo-device tun16'.  This will allow you to grow up
Xto sixteen neighbors before rebuilding your kernel with a
Xspecification like `pseudo-device tun17'.
X.LP
XThe number of PPP neighbors a system can have is independent of the
Xnumber of serial ports it contains, though it is constrained to that
Xmany simultaneous connections.  Outbound PPP links (initiated by this
Xsystem) are independent of inbound PPP links (initiated by a neighbor
Xsystem).  If a link might be initiated upon demand in either
Xdirection, then each system must arrange for both an outbound and an
Xinbound connection.
X.NH 3
XArranging for outbound PPP connections
X.LP
XWhenever \fIrobin\fP is booted, one PPP daemon must be started for
Xeach outbound link.  In this case, since \fIrobin\fP will call
X\fIlark\fP on demand, we add the following lines to the appropriate
Xspot in \fIrobin\fP's boot-time shell script (\fB/etc/rc.local\fP on
Xour example machine):
X.D1
X.ft 4
Xif [ -f /usr/etc/pppd ]; then
X	if [ -f /usr/adm/pppd.log ]; then
X		mv /usr/adm/pppd.log /usr/adm/OLDpppd.log
X	fi
X	pppd robin:sparrow auto up
X			(echo -n ' pppd(sparrow)')	>/dev/console
X	pppd robin:lark auto
X			(echo -n ' pppd(lark)')		>/dev/console
Xfi
X.ft P
X.D2
XThe daemons started here will look through \fB/etc/ppp.systems\fP to
Xfind entries for their destinations.
X.NH 3
XArranging for inbound PPP connections
X.LP
XAn account must be created for each machine that will initiate PPP
Xconnections to \fIrobin\fP.  In this case, since we expect \fIlark\fP
Xto dial us on demand, we add an entry to \fIrobin\fP's
X\fB/etc/passwd\fP file:
X.D1
X.ft 4
X# cat >> /etc/passwd
XPlark::105:20:Lark's PPP login:/tmp:/usr/local/etc/ppplogin
X^D
X# passwd Plark
XNew password: \fIsome password\fP
XRetype new password: \fIsome password\fP
X#
X.ft P
X.D2
Xwhere \fB/usr/local/etc/ppplogin\fP is an executable shell script that
Xlooks like
X.D1
X.ft 4
X# cat > /usr/local/etc/ppplogin
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty -tostop
Xexec pppd `hostname`: idle 130 crtscts
X^D
X# chmod 755 /usr/local/etc/ppplogin
X#
X.ft P
X.D2
XThe PPP user's login shell script can, of course, be located anywhere
Xand be named almost anything; we just use the above for purposes of
Xillustration.  On a NeXT\**
X.FS
XNeXT is a trademark of NeXT Computer, Inc.
X.FE
Xworkstation, the name of the user's login shell script may not contain
Xthe letter `r', because of an undocumented feature that would cause
X/bin/sh to consider itself to be a security-restricted shell.
X.LP
XIn most cases, all inbound PPP logins can use the same ppplogin
Xscript.  If you want to ensure that only a particular host can use a
Xparticular login, then have that login account use a private
X\fB/usr/local/etc/ppplogin-\fIhost\fR that looks something like
X.D1
X.ft 4
X# cat > /usr/local/etc/ppplogin-sparrow
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty -tostop
Xexec pppd `hostname`:sparrow idle 130 crtscts
X^D
X# chmod 755 /usr/local/etc/ppplogin-sparrow
X#
X.ft P
X.D2
X.NH 2
XCreating the PPP configuration files
X.LP
XNow we can start building our configuration files.  See
X\fBtun\fP\^(4), 
X\fBppp.devices\fP\^(5), \fBppp.dialers\fP\^(5), \fBppp.filter\fP\^(5),
X\fBppp.systems\fP\^(5), and \fBpppd\fP\^(8) for a description of all
Xthe configuration options, and see the \fBExamples/\fP subdirectory in
Xthe software distribution for some example configurations.  (Each
Xcomplete entry in \fBppp.dialers\fP and \fBppp.systems\fP must be
Xtyped on a single line.  The \fBppp.dialers\fP example here is broken
Xto fit on the paper.)
X.D1
X.ft 4
X# cd /etc
X# cat > ppp.devices
XTB-V32	cua	38400	crtscts
X^D
X# cat > ppp.dialers
XTB-V32	ABORT NO\\sCARRIER ABORT BUSY TIMEOUT 5 "" AT OK-AT-OK ATZ OK 
X	\\c TIMEOUT 30 "" ATX1S111=0DT\\T CONNECT \\c \\n
X^D
X# cat > ppp.filter
Xdefault	bringup	!ntp !3/icmp !who
X	pass	!who
X	keepup	!ntp !3/icmp !who
X	log	!nntp tcp/syn/recv
X^D
X# cat > ppp.systems
Xlark Any;50 ACU 38400 5551212 "" "" ogin: Probin word: \\qmypasswd
Xsparrow Anu;50 cub 38400 0 "" \\r\\r ogin: Probin word: \\qmypasswd
X^D
X# chmod 644 ppp.devices ppp.dialers ppp.filter
X# chmod 600 ppp.systems
X.ft P
X.D2
X.NH 2
XTesting the installation
X.LP
XOur PPP configuration is now complete, so we can go ahead and start it
Xup for testing:
X.D1
X.ft 4
X# pppd robin:lark auto
X#
X.ft P
X.D2
XAnd make sure it got started:
X.D1
X.ft 4
X# cat /usr/adm/pppd.log
X6/19-11:08:36-5997 Morning Star Technologies PPP
X6/19-11:08:36-5997 Version 1.0 Alpha [17-Jun-1991 21:52:49]
X6/19-11:08:36-5997 du0: pppd robin:lark auto 
X#
X.ft P
X.D2
XAnd bring up the link: 
X.D1
X.ft 4
X# telnet lark
XTrying lark ...
XConnected to lark.
XEscape character is '^]'.
X
X
XSunOS 4.1 UNIX (lark) (ttyp3)
X
Xlark login: ^DConnection closed by foreign host.
X#
X.ft P
X.D2
XAnd watch how the link was initiated:
X.D1
X.ft 4
X# cat /usr/adm/pppd.log
X6/19-11:08:36-5997 Morning Star Technologies PPP
X6/19-11:08:36-5997 Version 1.0 Alpha [17-Jun-1991 21:52:49]
X6/19-11:08:36-5997 du0: pppd robin:lark auto 
X6/19-11:08:45-5997 tcp 137.175.2.11/1204 -> 131.187.1.131/telnet 40 syn bringup
X6/19-11:08:45-5997 Dialing lark (cua/38400/5551212/TB-V32)
X6/19-11:09:23-5997 Call succeeded
X6/19-11:09:37-5997 PPP connected to lark
X6/19-11:10:34-5997 tcp 137.175.2.2/smtp <- 129.221.8.2/2547 40 syn
X#
X.ft P
X.D2
XThis log file snippet shows that our \fItelnet\fP session to
X\fIlark\fP was the cause for the link being initiated.  It also shows
Xthat the `log' line in \fBppp.filter\fP is operating as expected, and
Xthat the first incoming TCP connection was to deliver mail.
X.LP
XMorning Star PPP is installed, configured, running and connected on
Xboth of our links.  When the link is up, users should be able to
Xaccess \fIrobin\fP from a remote machine via \fIrlogin\fP\^.  You
Xshould also be able to \fItelnet\fP, \fIftp\fP, etc. between the two.
X.\" 
X.\" .NH 1
X.\" IP Routing tips
X.\" .LP
X.\" Watch this space...
X.\" .NH 1
X.\" Finer points of the configuration files
X.\" .LP
X.\" Just keep playing with them, you'll get it right eventually.  Watch
X.\" this space for hints.
X.NH 1
XObservations about on-demand dialup IP
X.NH 2
XApplication behavior
X.LP
XThe scheme used to support on-demand dialups in Morning Star PPP
Xdepends upon network- and higher-layer protocol timeouts being
Xtypically longer than the time needed to allocate a modem, dial it,
Xcomplete the call, login to the remote system, start up the PPP
Xprotocol handler there, and establish LCP and IPCP connectivity.  This
Xis a reasonable assumption, since a local call will typically require
Xabout 25 seconds between the daemon's receipt of the first `bringup'
Xpacket and the establishment of IP-level connectivity (of that, more
Xthan 20 are consumed with dialing the call and training the modems).
XThis scheme works even if the first remote modem is busy and the
Xdialing pppd must try a second telephone number, so long as the dialer
Xscript is carefully written to include appropriate ABORT and TIMEOUT
Xstrings.  The user's application will simply wait for the connection
Xto be established and continue as if the connection had always been in
Xplace.  This even works well when a link times out with active TCP
Xsessions in place, such as a \fItelnet\fP connection to the remote
Xend.  When the user types, or when an application writes output, a new
Xcall is placed from either end and the session is re-established
Xwithout TCP or the application above it noticing anything was amiss.
X.SP
XUnfortunately, if the connection cannot be re-established, TCP will
Xtime out and the application may fail ungracefully.  This most often
Xhappens during times of resource contention (no free modems to place
Xor answer the call) or acute connectivity problems (telephone system
Xcall-routing breakdown or extreme service degradation).  The effect
Xwill be the same as if the `other' end had crashed ungracefully, since
Xthe application will only be able to tell that it is unable to
Xexchange packets with its partner.
X.NH 2
XDealing with bandwidth limitations
X.NH 3
XApplications with few problems on thin wires
X.LP
XPPP over current-technology dial modems\**
X.FS
XCCITT V.32 (9600 baud) or V.32bis (14400 baud) carrier, with V.42
Xerror correction and V.42bis data compression, and the host serial
Xinterface latched at 38400 baud
X.FE
Xprovides satisfactory performance for most typical TCP/IP and UDP/IP
Xwide-area applications.  Especially with TCP header compression, users
Xwill experience useful file transfer throughput (V.32/V.42bis yields
X1.7-2.8 Kbytes/sec for a typical large binary data file) and
Xreasonable interactive response in applications such as \fItelnet\fP,
X\fIrlogin\fP, and the like.  Plenty of bandwidth is available for
Xnetwork infrastructure applications such as SMTP electronic mail, NNTP
Xnetwork news, NTP clock synchronization, domain name service, etc.
X.NH 3
XApplications with some problems on thin wires
X.LP
XThe speed limitation of the dialup medium becomes more apparent when
Xlarger amounts of data are transferred, particularly for interactive
Xapplications such as \fIxterm\fP or other display-oriented programs.
XWhile large bitmap editors and CAD packages will operate correctly,
Xusers may find that the modem simply isn't able to keep up with their
Xdemands for interactive responsiveness.
X.\" The need for more PPP bandwidth will be addressed in future
X.\" Morning Star products, both for dialup and for leased-line applications.
X.NH 3
XApplications to avoid on thin wires
X.LP
XApplications that are extreme users of communications bandwith, such
Xas Sun's Network File System (NFS\**), 
X.FS
XNFS is a trademark of Sun Microsystems, Inc.
X.FE
Xshould be avoided over dialup links except in cases of dire necessity.
XNot only is NFS able to easily overwhelm a modem link, it is a
XUDP-based application, so the user will not enjoy the packet overhead
Xreduction benefits of TCP header compression.  While performance may
Xbe marginally acceptable for read-only file access, NFS's synchronous
Xwrite semantics will make file creation and writing quite painful.
XAttempting to execute a program stored on a remotely-mounted
Xfilesystem will have this same problem, since it will be swapped to
Xthe same file from which it was read.
X.SP
XFortunately, there are usually other approaches, more appropriate for
Xwide-area networking over low-bandwith links, to solving the problems
Xthat NFS addresses.  Use Berkeley's \fIrdist\fP system to keep the
Ximportant segments of two sites' file structures in reasonable
Xsynchrony.  Also, use a package like ange-ftp.el\**
X.FS
XWritten by Andy Norman <ange@hplb.hpl.hp.com>, available from
Xftp.cis.ohio-state.edu:pub/gnu/emacs/elisp-archives/packages/ange-ftp.el.Z
X.FE
Xin your GNU Emacs to automatically manage FTP connections that are
Xtransparently associated with your editing buffers.  This gives the
Xappearance of the ability to edit files while they reside on a remote
Xmachine, without needing to use NFS to mount the remote filesystems
Xlocally.
X.SP
XIf, even after the above attempts at dissuasion, you still think that
Xyou absolutely must use NFS, set the \fIrsize\fP and \fIwsize\fP
Xparameters on the mount request to something like 1400 (to fit safely
Xwithin the usual PPP MRU/MTU of 1500, even with possible
Xspecial-character escaping as per the \fIasyncmap\fP\^), and increase
Xthe \fItimeo\fP timeout parameter to accomodate network delays.
X.NH 1
XCabling
X.LP
XMost systems and modems use the EIA RS-232\**
X.FS
XElectronic Industries Association, EIA Standard RS-232-C, `Interface
XBetween Data Terminal Equipment and Data Communications Equipment
XEmploying Serial Binary Data Interchange', August 1969.
X.FE
Xsignalling conventions for their asynchronous serial ports.  In the
Xtables below, there is no difference between the pins referred to as
X`DTE pins' or `Modem pins', nor between `Local pins' and `Remote
Xpins', except notational convenience.  If a cable has the same
Xphysical connector type on each end (both DB-25 or both MiniDIN-8), it
Xis completely symmetrical and may be flipped end-for-end with no
Xeffect.
X.NH 2
XAsynchronous Modem cables
X.LP
XIf your system is to be connected to an asynchronous modem, and if the
Xsystem uses DB-25 connectors, the pins on the system (DTE) end of the
Xcable should be connected straight through to the same-numbered pins
Xon the DB-25 modem end.  In order of importance for proper operation,
Xthe pins you should connect are
X.TS
Xcenter tab (\);
Xlb lb lb lb
Xl  l  l  l .
XDTE DB-25 pin\RS-232 Signal\Modem DB-25 pin\Direction
X1\Protective Ground\1\both
X7\Signal Ground (GND)\7\both
X2\Transmit Data (TD)\2\from DTE
X3\Receive Data (RD)\3\from Modem
X6\Data Set Ready (DSR)\6\from Modem
X20\Data Terminal Ready (DTR)\20\from DTE
X4\Request To Send (RTS)\4\from DTE
X5\Clear To Send (CTS)\5\from Modem
X8\Data Carrier Detect (DCD)\8\from Modem
X22\Ring Indicator (RI)\22\from Modem
X.TE
X.LP
XNeXT systems' serial ports have MiniDIN-8 connectors.  A cable to
Xconnect a NeXT system to a DB-25 asynchronous modem looks like\**
X.FS
X`Network and System Administration', Chapter 13 `Attaching Peripheral
XDevices', section on `Serial Port Connector and Cable Specifications',
Xpps 186-188, NeXT Computer Inc., 1990.
X.FE
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XDTE MiniDIN-8 pin%RS-232 Signal%Modem DB-25 pin%Direction
X1%Data Terminal Ready (DTR)%20%from DTE
X2%Data Carrier Detect (DCD)%8%from Modem
X3%Transmit Data (TD)%2%from DTE
X4%Signal Ground (GND)%7%both
X5%Receive Data (RD)%3%from Modem
X6%Request To Send (RTS)%4%from DTE
X7%\fInot connected\fP%\fInot connected\fP%\fInot connected\fP
X8%Clear To Send (CTS)%5%from Modem
Xframe%Protective Ground%frame%both
X\fInot connected\fP%Data Set Ready (DSR)%6%from Modem
X\fInot connected\fP%Ring Indicator (RI)%22%from Modem
X.TE
X.NH 2
XAsynchronous `Null-Modem' cables
X.LP
XIf your system is to be connected directly to another system, the pins
Xon the local system's end of the cable should be connected with the
Xsymmetric-function pins on the remote system's end.  This is commonly
Xcalled a null-modem cable.  In order of importance for proper
Xoperation, the pins you should attach between two systems with DB-25
Xconnectors are
X.TS
Xcenter tab (\);
Xlb lb lb lb
Xl  l  l  l .
XLocal DB-25 pin\Local RS-232 Signal\Remote DB-25 pin\Remote RS-232 Signal
X1\Protective Ground\1\Protective Ground
X7\Signal Ground (GND)\7\Signal Ground (GND)
X2\Transmit Data (TD)\3\Receive Data (RD)
X3\Receive Data (RD)\2\Transmit Data (TD)
X6\Data Set Ready (DSR)\20\Data Terminal Ready (DTR)
X20\Data Terminal Ready (DTR)\6\Data Set Ready (DSR)
X4\Request To Send (RTS)\5\Clear To Send (CTS)
X5\Clear To Send (CTS)\4\Request To Send (RTS)
X.TE
X.LP
XNeXT systems' serial ports have MiniDIN-8 connectors.  A cable to
Xconnect a NeXT system to another system that has DB-25 connectors
Xlooks like
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XLocal MiniDIN-8 pin%Local RS-232 Signal%Remote DB-25 pin%Remote RS-232 Signal
X1%Data Terminal Ready (DTR)%8%Data Carrier Detect (DCD)
X2%Data Carrier Detect (DCD)%20%Data Terminal Ready (DTR)
X3%Transmit Data (TD)%3%Receive Data (RD)
X4%Signal Ground (GND)%7%Signal Ground (GND)
X5%Receive Data (RD)%2%Transmit Data (TD)
X6%Request To Send (RTS)%5%Clear To Send (CTS)
X7%\fInot connected\fP%\fInot connected\fP%\fInot connected\fP
X8%Clear To Send (CTS)%4%Request To Send (RTS)
Xframe%Protective Ground%frame%Protective Ground
X\fInot connected\fP%Data Set Ready (DSR)%6%Data Set Ready (DSR)
X\fInot connected\fP%Ring Indicator (RI)%22%Ring Indicator (RI)
X.TE
X.LP
XA cable to connect a pair of NeXT systems looks like
X.TS
Xcenter tab (%);
Xlb lb lb lb
Xl  l  l  l .
XLocal MiniDIN-8 pin%Local RS-232 Signal%Remote MiniDIN-8 pin%Remote RS-232 Signal
X1%Data Terminal Ready (DTR)%2%Data Carrier Detect (DCD)
X2%Data Carrier Detect (DCD)%1%Data Terminal Ready (DTR)
X3%Transmit Data (TD)%5%Receive Data (RD)
X4%Signal Ground (GND)%4%Signal Ground (GND)
X5%Receive Data (RD)%3%Transmit Data (TD)
X6%Request To Send (RTS)%8%Clear To Send (CTS)
X7%\fInot connected\fP%7%\fInot connected\fP
X8%Clear To Send (CTS)%6%Request To Send (RTS)
Xframe%Protective Ground%frame%Protective Ground
X.TE
X.NH 1
XFlow control
X.LP
XIf your UNIX system supports it, use out-of-band `hardware' (RTS/CTS)
Xflow control between your system and your modem, or between two
Xsystems over a null-modem cable.  On a Sun system, specify `crtscts'
Xeither on the \fIpppd\fP command line, or in the Optional Parameters
Xfield of the line in \fBppp.devices\fP\^(5).  On a NeXT system,
Xspecify `cufa' in the Device field in \fBppp.devices\fP\^(5).
X.LP
XIf, for whatever reason, you are forced to use in-band `software'
X(XON/XOFF, ^Q/^S) flow control, then specify `xonxoff' on the
X\fIpppd\fP command line or in \fBppp.devices\fP\^(5) (on a Sun), or
Xuse `cua' on a NeXT.
X.LP
XThe default is to use no flow control.
X.LP
XSunOS 4.1.1 implements hardware flow control on the native CPU serial
Xports only for transmission\**.
X.FS
XSee the Output Modes section of \fBtermio\fP\^(4) and the IOCTLS section of
X\fBzs\fP\^(4s).
X.FE
XWorkstations running this OS respect the modem's use of CTS to
Xindicate its readiness to receive characters from the host, but do not
Xuse RTS to throttle the modem's data stream to the host.  This means
Xthat when presented with a heavy incoming traffic load, the Sun's
Xnative CPU serial ports will be overloaded, and the console will
Xreport a series of occasional `zs1: silo overflow' errors.  This is
Xunfortunate but unavoidable by PPP, introduces no errors into the data
Xbeing transferred across the network, and does not measurably affect
Xthe PPP link's throughput or responsiveness.
X.NH 1
XModem parameters
X.NH 2
XGeneral Recommendations
X.LP
XYou should connect your modem to your computer at the highest
Xasynchronous serial speed that both can support (typically 38400 baud,
Xas found in /usr/include/sys/ttydev.h), and allow the modem's internal
Xcarrier speed matching capability to make a usable connection with
Xwhatever type of modem is in use at the other end.  This will allow
Xyou to take maximum advantage of the modem's data compression
Xcapabilities.  
X.LP
XIf your modem supports error correction, you should enable its use.
XThis will allow line noise problems to be corrected at as low a level
Xin the protocol stack as possible.  If the modem has both MNP\**
X.FS
XMNP is a trademark of Microcom Inc.
X.FE
Xlevel
X4 and CCITT V.42, choose the latter so that you can also use CCITT
Xdata compression.
X.LP
XIf your modem supports data compression, you probably should enable
Xits use unless your tests show your application has preferable
Xperformance attributes without it.  This will allow you to pass as
Xmuch information across the PPP line as possible.  If the modem has
Xboth MNP5 and CCITT V.42bis, choose the latter because it has a higher
Xmaximum compression ratio and because it behaves better with
Xprecompressed data streams.
X.NH 2
XSpecific examples
X.LP
XIn the file \fBExamples/ppp.dialers.ex\fP you'll find dialer
Xdescriptions for a few types of modems.  Since your modems will likely
Xbe used for purposes besides PPP (e.g. UUCP or interactive users),
Xit's best to set them up for efficiency in all possible uses.  The
XPPP-specific register settings in ppp.dialers ensure that an otherwise
Xgeneral-purpose modem will work as well as possible with PPP, for the
Xduration of the PPP session.
X.LP
XIn the examples below, we'll show how to configure a typical modern
Xmodem, including a picture of its working register settings and a
Xcommand string that will set it up correctly.  We'll also describe
Xwhat each of those register settings mean, so that if you use a
Xdifferent type of modem, you should be able to set it up similarly.
X.LP
XWe find that a Telebit T1600 works well with the following register
Xsettings:
X.D1
X.SM
X.ft 4
X.ta \w''u \w'S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u \w'S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ S000=000\ \ 'u
XOK
Xat&v
XT1600 - Version LA1.00  - Active Configuration
X B1  E1  L3  M0  Q2  T   V1  X12  Y0
X&C1 &D3	&G0 &J0	&L0 &Q0	&R3 &S1	&T4 &X0
XS000:1	S001=0	S002=43	S003=13	S004=10	S005=8	S006=2	S007:120
XS008=2	S009=6	S010=14	S011=70	S012=50	S018=0	S025=5	S026=1
XS038=0	S041=0	S045=0	S046=0	S047=4	S048=0	S050=0	S051:6
XS056=17	S057=19	S058:2	S059:15	S060=0	S061:0	S062=15	S063:2
XS064=0	S068=255	S069=0	S090=0	S093=8	S094=1	S100=0	S102=0
XS104=0	S105=1	S111:0	S112=1	S180=2	S181=1	S183=25	S190=1
XS253=10	S254=255	S255=255
XOK
X.ft P
X.NL
X.D2
X.SP
XYou can make a T1600 work like this by giving it the following
Xcommand:
X.D1
X.ft 4
Xat&fs0=1s7=120s51=6s58=2s59=15s61=0s63=2s111=255l3m0q2tx12&c1&d3&s1&w
X.ft P
X.D2
X.SP
XThis accomplishes the following:
X.RS
X.IP "&f" "\w's111=255\ \ 'u"
XLoads factory default settings.
X.IP "s0=1"
XAnswer after one ring.
X.IP "s7=120"
XWait 120 seconds for a valid carrier tone to be sent from the remote
Xmodem.
X.IP "s51=6"
XLatch the DTE interface at 38400 bps.
X.IP "s58=2"
XUse full-duplex RTS/CTS flow control.  When RTS is OFF, the modem will
Xnot send data to the local DTE.  When RTS is ON the modem sends data
Xto the local DTE.
X.IP "s59=15"
XUse the following result code suffixes:
X.RS
X.nf
XPossible link protocol suffixes: nothing, REL, or LAPM
XPossible compression suffixes: nothing or COMP
X.fi
X.RE
X.IP "s61=0"
XLocal reaction to a break signal on the serial interface is the same
Xas specified in S63.
X.IP "s63=2"
XWhen a break signal is transmitted by the local DTE during an error
Xcontrolled connection, the modem will discard any buffered data and
Xsend the break.
X.IP "s111=255"
XUse the file transport protocol spoofing mechanism specified by the
Xremote modem.  If both modems have S111=255, no protocol is spoofed.
X.IP "l3"
XSets the speaker volume high.
X.IP "m0"
XTurns off the speaker.
X.IP "q2"
XModem reports result codes when originating a call, but does not
Xreturn result codes when answering a call.
X.IP "t"
XModem uses DTMF tone dialing.
X.IP "x12"
XResult codes include the following:
X.RS
X.nf
XBUSY
XDIALING
XERROR
XNO CARRIER
XNO DIALTONE
XOK
XRING
XRRING
XCONNECT 300
XCONNECT 1200
XCONNECT 2400
XCONNECT 4800
XCONNECT 7200
XCONNECT 9600
XCONNECT 12000
XCONNECT 14400
XCONNECT 19200
XCONNECT 38400
X.fi
X.RE
X.IP "&c1"
XWhen a carrier is detected from the remote modem, the DCD signal is
Xturned ON after the CONNECT result code is sent to the DTE.  The DCD
Xsignal is turned OFF when the carrier is dropped.
X.IP "&d3"
XThe modem resets and enters command mode when the DTR signal is
Xswitched from ON to OFF.  This causes the modem to recall the current
Xuser configuration parameters from nonvolatile memory.
X.IP "&s1"
XDSR is ON after the answer tone is detected and stays ON throughout
Xthe connection.
X.IP "&w"
XSaves the current configuration settings to nonvolatile RAM.
X.RE
X.LP
XIf you have some other sort of modem that's not described here, you
Xshould configure it with similar functions (e.g. RTS/CTS flow control)
Xusing that modem's own command set and register semantics.
X.NH 1
XInteroperability with other PPP implementations
X.NH 2
XThe Telebit NetBlazer\**
X.FS
XNetBlazer is a trademark of Telebit Corporation.
X.FE
X.LP
XMorning Star PPP has been tested with version 1.20 of Telebit's
XNetBlazer software.
XWe were unable to configure the NetBlazer to negotiate the use of RFC
X1144 `VJ' TCP header compression, though we are assured that future
Xversions of the NetBlazer software will incorporate this feature.  It
Xwill probably not require the use of \fBpppd\fP\^'s `old' argument.
X.NH 3
XDialing into a NetBlazer from a UNIX system
X.LP
XThis would be the arrangement to allow several remote workstations to
Xdial into a NetBlazer serving as a hub.
X.NH 4
XConfiguring the NetBlazer
X.LP
XThe NetBlazer may be set up as if the UNIX machine were just another
Xremote `dynamic-interface' NetBlazer, using the PPP encapsulation
Xprotocol in `packet mode'.
X.LP
XConfigure the NetBlazer as described in chapter 3 of the NetBlazer
XReference Manual, noting particularly the discussion of the
X\fBipdial\fP command in the section on Setting Up Remote IP
XDestinations.  When queried for `Name of dial IP interface to add',
Xrespond with the name of the UNIX system.  Morning Star PPP does not
Ximplement a `crypto handshake' to exchange with the NetBlazer.  Use
XPPP rather than SLIP, and specify 1500 for the MTU.  When asked to
Xenter the password for the dial-in user for use by the UNIX system,
Xnote that password for later inclusion in the UNIX system's
X\fB/etc/ppp.systems\fP entry that describes how to dial into this
XNetBlazer.
X.NH 4
XConfiguring the UNIX system
X.LP
XIn your UNIX system's \fB/etc/ppp.systems\fP\^, the username provided
Xby the login portion of the chat script will be the name of the UNIX
Xsystem itself.  The password will be the one provided when arranging
Xfor the dial-in user on the NetBlazer.
X.LP
XIn your UNIX system's \fB/etc/rc.local\fP\^, start the Morning Star
XPPP daemon with the `active' argument, because the NetBlazer starts in
Xthe LCP Passive-Open state.
X.D1
X.ft 4
Xpppd `hostname`:remote-netblazer auto active idle 130
X.ft P
X.D2
X.NH 3
XDialing into a UNIX system from a NetBlazer
X.LP
XThis would be the arrangement to allow a hub NetBlazer to connect on
Xdemand to several remote workstations.  \fI(This direction hasn't all
Xbeen worked out quite yet.)\fP
X.NH 4
XConfiguring the UNIX system
X.LP
XIn order to accomodate a NetBlazer dialing into a UNIX system running
XMorning Star PPP, the following changes must be made to the UNIX
Xsystem.  Make an entry in /etc/gettytab that's a duplicate of the
Xentry you would normally have used, except with the addition of the
X\fB:p8:\fP parameter (see \fBgettytab\fP\^(5)), like this:
X.D1
X.ft 4
Xh|std.38400|38400-baud:sp#38400:
Xw|P.38400|38400-baud:sp#38400:p8:
X.ft P
X.D2
XThen change /etc/ttytab to use the new entry, like this:
X.D1
X.ft 4
X#ttya	"/usr/etc/getty std.38400"	dialup		on # T1600
Xttya	"/usr/etc/getty P.38400"	dialup		on # T1600
X.ft P
X.D2
X.LP
XThe login shell script for the NetBlazer's incoming connection must
Xtell the NetBlazer what it expects to hear ("Packet mode enabled")
Xbefore starting the PPP LCP option negotiation phase of the
Xconnection.  Since the NetBlazer does not perform IPCP `IP-Addresses'
Xnegotiation, the UNIX PPP must tell the NetBlazer what IP address it
Xshould be.
X.D1
X.ft 4
X# cat > /usr/local/etc/ppplogin-netblazer
X#!/bin/sh
X
XPATH=/usr/bin:/usr/etc
X
Xmesg n
Xstty -tostop
Xecho "Packet mode enabled"
Xexec pppd `hostname`:remote-netblazer idle 130 crtscts timeout 15
X^D
X# chmod 755 /usr/local/etc/ppplogin-netblazer
X#
X.ft P
X.D2
XThe name \fIremote-netblazer\fP in the above shell script should be
Xreplaced with the IP address of the NetBlazer that will be connecting,
Xor its name if its address can be found in the local hosts table or
Xcan be resolved by the local name server before the NetBlazer link is
Xavailable.
X.NH 4
XConfiguring the NetBlazer
X.LP
XChange the ICS entry in the NetBlazer's chat.txt file so that it looks
Xfor `word:' rather than `password:' in the e4 line.  This is because
Xsome UNIX \fIlogin\fP programs say `Password:' with a capital `P',
Xwhich won't match the NetBlazer's desired lower-case `p'.  Looking for
Xthe string `word:' should work correctly in any case, and will not
Xaffect the NetBlazer's operation in general.
X.LP
XYou may also need to extend the timeout period of the e7 line to
Xsomething like
X.D1
X.ft 4
Xe7,20,30,99,Packet mode enabled
X.ft P
X.D2
XThis similarly will not adversely affect the NetBlazer's operation.
X.NH 2
XFTP Software Inc's PC/TCP\** Network Software for DOS
X.FS
XPC/TCP and FTP Software are registered trademarks of FTP Software, Inc.
X.FE
X.LP
XMorning Star PPP is being tested with version 2.05 of FTP Software
XInc's PC/TCP PPP (PC-227) implementation.
X.NH 3
XGetting ready for a PC to dial into a UNIX system
X.LP
XWatch this space...
X.NH 3
XGetting a PC ready to dial into a UNIX system
X.LP
XWatch this space...
X.NH 1
XCredits
X.LP
XParts of the protocol engine are derived from code written by Drew D.
XPerkins, ddp@andrew.cmu.edu, now ddp@interstream.com.
X.NH 1
XCopyright Information
X.LP
XThis software is Copyright 1991 Morning Star Technologies, all rights
Xreserved.  It contains software developed at Carnegie Mellon
XUniversity which is Copyright 1989 Carnegie Mellon University, all
Xrights reserved.
X
X.\" Local Variables:
X.\" mode: electric-nroff
X.\" compile-command: "groff -t -ms -TX75 intro.ms"
X.\" End:
END_OF_FILE
if test 37207 -ne `wc -c <'ppp/man/test.ms'`; then
    echo shar: \"'ppp/man/test.ms'\" unpacked with wrong size!
fi
# end of 'ppp/man/test.ms'
fi
if test ! -d 'ppp/system' ; then
    echo shar: Creating directory \"'ppp/system'\"
    mkdir 'ppp/system'
fi
if test ! -d 'ppp/system/sun' ; then
    echo shar: Creating directory \"'ppp/system/sun'\"
    mkdir 'ppp/system/sun'
fi
if test ! -d 'ppp/system/next' ; then
    echo shar: Creating directory \"'ppp/system/next'\"
    mkdir 'ppp/system/next'
fi
if test -f 'ppp/system/sun/README' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/system/sun/README'\"
else
echo shar: Extracting \"'ppp/system/sun/README'\" \(6208 characters\)
sed "s/^X//" >'ppp/system/sun/README' <<'END_OF_FILE'
X
X		      Morning Star Technologies
X		       PPP Installation for the
X		  Sun SparcStation Running SunOS 4.*
X
X
XTo install Morning Star PPP, do the following:
X
X- If you are running SunOS version 4.0.3c and will be running PPP over
X  the native serial ports on your workstation, you will need to
X  replace the distributed pppd with one that works around a bug in the
X  4.0.3c tty driver:
X
X    # mv pppd pppd.ORIG
X    # ln pppd-4.0.3c pppd
X
X- Run the Install shell script.  This will create directories, install
X  files and make devices as necessary.  It will also create
X  /etc/ppp.uninstall, which will remove the installed files.
X
X- Insert the following lines into /sys/conf.common/files.cmn:
X
X    os/tun.c			optional tun
X    os/tun_conf.c		optional tun
X
X- Edit /sys/sun/conf.c and add the following lines before the
X  declaration of cdevsw[]:
X
X    # include "tun.h"
X    # if NTUN > 0
X    extern int tunopen(), tunclose(), tunread(), tunwrite(), tunioctl(),
X	  tunselect();
X    # else
X    # define tunopen      nodev
X    # define tunclose     nodev
X    # define tunread      nodev
X    # define tunwrite     nodev
X    # define tunioctl     nodev
X    # define tunselect    nodev
X    # endif
X
X- Still editing /sys/sun/conf.c, add the following lines to the end of
X  the initialization of cdevsw[] (also, make sure that the preceding
X  entry has a comma following its closing brace):
X
X    {
X        tunopen,     tunclose,    tunread,     tunwrite,    /*104*/
X        tunioctl,    nodev,       tunselect,   0,
X        0,           0,
X    },
X
X- The last zero and its comma in the above structure should be removed
X  if you are running SunOS version 4.0.3c.  Change the comment
X  (``/*104*/'' in the above example) so that it reflects the correct
X  index into the cdevsw[] table.  Use this number (the major device
X  number of the IP tunnel driver) to create the device entries in
X  /dev.  Make enough devices (up to 128 pairs) to have one pair
X  (0/128, 1/129, etc.) per PPP neighbor.  The shell program
X  ``makedev.tun'' makes this easy:
X
X    # ./makedev.tun
X    What is the major device number of the ``tun'' device driver? 104
X    How many IP tunnel devices do you want? [16] 4
X    mknod /dev/tun0 c 104 0; chown root /dev/tun0; chmod 600 /dev/tun0
X    mknod /dev/tun128 c 104 128; chown root /dev/tun128; chmod 600 /dev/tun128
X    mknod /dev/tun1 c 104 1; chown root /dev/tun1; chmod 600 /dev/tun1
X    mknod /dev/tun129 c 104 129; chown root /dev/tun129; chmod 600 /dev/tun129
X    mknod /dev/tun2 c 104 2; chown root /dev/tun2; chmod 600 /dev/tun2
X    mknod /dev/tun130 c 104 130; chown root /dev/tun130; chmod 600 /dev/tun130
X    mknod /dev/tun3 c 104 3; chown root /dev/tun3; chmod 600 /dev/tun3
X    mknod /dev/tun131 c 104 131; chown root /dev/tun131; chmod 600 /dev/tun131
X
X- Add the following line to the end of your kernel configuration file
X  in the /sys/sun4c/conf (or /sys/sun4/conf) directory (assumed to be
X  MST in the following paragraphs):
X
X    pseudo-device   tun           # Morning Star IP tunnel driver
X
X  By default, this will prepare sixteen tunnel devices (as if you had
X  said "pseudo-device tun16").  If you expect to have more than sixteen
X  PPP neighbors, increase the number of configured tunnel devices.  For
X  example, if you expect to have twenty-three PPP neighbors, say
X  ``pseudo-device tun23'' instead.
X
X- Build a new kernel:
X
X    # cd /sys/sun4c/conf (or /sys/sun4/conf)
X    # /etc/config MST
X    # cd ../MST
X    # make
X    (lots of output)
X
X- Save the old kernel, then move the new kernel to /vmunix.
X
X    # mv /vmunix /vmunix.previous
X    # mv vmunix /
X
X- Reboot the system.
X
X    # /etc/reboot
X
X- If there are any problems with the new kernel, you can reboot using
X  the previous version of the kernel (vmunix.previous) saved above.
X
X- Create "Auto-Call Unit" devices corresponding to the tty devices:
X
X    # ls -lg /dev/tty[ab]
X    crw--w--w-  1 root     wheel     12,   0 Jun 10 18:09 /dev/ttya
X    crw--w--w-  1 root     wheel     12,   1 Jun 10 16:40 /dev/ttyb
X    # mknod /dev/cua c 12 128
X    # mknod /dev/cub c 12 129
X    # chown root /dev/cu[ab]
X    # chgrp wheel /dev/cu[ab]
X    # chmod 666 /dev/cu[ab]
X    # ls -lg /dev/{tty,cu}[ab]
X    crw-rw-rw-  1 root     staff     12, 128 Jun  4 17:27 /dev/cua
X    crw-rw-rw-  1 root     staff     12, 129 Jun 20 14:39 /dev/cub
X    crw--w--w-  1 root     wheel     12,   0 Jun 10 18:09 /dev/ttya
X    crw--w--w-  1 root     wheel     12,   1 Jun 10 16:40 /dev/ttyb
X    #
X
X- If you are running SunOS 4.0 or 4.0.3c, configure your EEPROMs
X  correctly.  We find that the following works well on a SPARCstation,
X  using hardware (RTS/CTS) flow control.
X
X    # eeprom ttya-mode=19200,8,1,n,h
X    # eeprom ttya-rts-dtr-off=false
X    # eeprom ttya-ignore-cd=false
X    # eeprom ttyb-mode=38400,8,1,n,h
X    # eeprom ttyb-rts-dtr-off=false
X    # eeprom ttyb-ignore-cd=false
X    #
X
X  You must turn your Sun off and back on again for the new EEPROM
X  parameters to take effect.
X
X- If your tty ports are to be used for inbound as well as outbound
X  connections, use lines like the following in /etc/ttytab:
X
X    # egrep ttya\|ttyb /etc/ttytab
X    ttya    "/usr/etc/getty std.19200"      unknown         on # T2500
X    ttyb    "/usr/etc/getty std.38400"      unknown         on # T1600
X    #
X
X  Without rebooting, you can cause the new ttytab settings to take
X  effect by saying:
X
X    # kill -HUP 1
X
X  Also, if you are running SunOS 4.1 or 4.1.1, disable soft carrier:
X
X    # ttysoftcar -a
X
XTo complete the installation, do the following:
X
X- Read the ppp.devices(5), ppp.dialers(5), ppp.filter(5),
X  ppp.systems(5) and pppd(8) manual pages, along with the introductory
X  document, intro.ms.
X
X- Create /etc/ppp.systems, /etc/ppp.devices, /etc/ppp.dialers and
X  /etc/ppp.filter files.  Suggestions are available in the Examples
X  subdirectory.  Create a login shell script such as /usr/etc/ppplogin
X  and a login in /etc/passwd that uses it (see pppd(8)).
X
X- Test your configuration by running pppd manually.
X
X- Add commands to /etc/rc.local to start pppd at boot time (see pppd(8)).
X
XIf you have any problems with this software, send electronic mail to
Xsupport@MorningStar.Com, or call +1-800-558-7827 or +1-614-451-1883 and
Xask for support.
END_OF_FILE
if test 6208 -ne `wc -c <'ppp/system/sun/README'`; then
    echo shar: \"'ppp/system/sun/README'\" unpacked with wrong size!
fi
# end of 'ppp/system/sun/README'
fi
if test -f 'ppp/system/next/README' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'ppp/system/next/README'\"
else
echo shar: Extracting \"'ppp/system/next/README'\" \(2028 characters\)
sed "s/^X//" >'ppp/system/next/README' <<'END_OF_FILE'
X
X			Morning Star PPP
X
XYou have installed Morning Star PPP, a software communications package
Xfor providing flexible and inexpensive Internet-style connectivity
Xusing standard autodial modems attached to the ttya or ttyb ports of
Xthe NeXT workstation.
X
XRun the ppp.install shell script to complete the software installation
Xprocess.
X
XRead the ppp.devices(5), ppp.dialers(5), ppp.filter(5), ppp.systems(5)
Xand pppd(8) manual pages.
X
XCreate /etc/ppp.systems, /etc/ppp.devices, /etc/ppp.dialers and
X/etc/ppp.filter files.  Suggestions are available in the
X/LocalApps/ppp/Examples directory.  Create a login shell script such
Xas /usr/etc/ppplogin and a login in /etc/passwd that uses it (see
Xpppd(8)).
X
XTo use RTS/CTS "hardware" flow control with a modem, first specify the
Xcorrect tty device in /etc/ttys for inbound calls:
X    #ttya   "/usr/etc/getty std.9600"       unknown         off secure
X    ttydfa  "/usr/etc/getty std.38400"      dialup          on
XAlso specify "cufa" in ppp.devices.  Refer to NeXT's "Network and
XSystem Administration", pps 182-185.  There's no need to specify
X"crtscts" on the daemon command line or in ppp.devices.
X
XTo use XON/XOFF ^S/^Q "software" flow control with a modem, first
Xspecify the correct tty device in /etc/ttys for inbound calls:
X    #ttya   "/usr/etc/getty std.9600"       unknown         off secure
X    ttyda   "/usr/etc/getty std.38400"      dialup          on
XAlso specify "cua" in ppp.devices.  Refer to NeXT's "Network and
XSystem Administration", pps 182-185.  There's no need to specify
X"xonxoff" on the daemon command line or in ppp.devices.
X
XTest your configuration by running pppd manually.
X
XWhen you are convinced that it works correctly, add commands to
X/etc/rc.local to start the daemon automatically at boot time (triple
Xcheck your work -- /etc/rc.local is a bad place to make a mistake),
Xand reboot to verify it.
X
XIf you have any problems with this software, send electronic mail to
Xsupport@MorningStar.Com, or call +1 800 558 7827 or +1 614 451 1883
Xand ask for support.
END_OF_FILE
if test 2028 -ne `wc -c <'ppp/system/next/README'`; then
    echo shar: \"'ppp/system/next/README'\" unpacked with wrong size!
fi
# end of 'ppp/system/next/README'
fi
echo shar: End of shell archive.
exit 0
