				Dialup PPP
				Release 3.0beta
				Kirk Smith
				Purdue University
				July 1993

1.  Introduction

1.1 General

This software was developed to provide dialup on demand PPP over high
speed modems.  In many situations, leased lines are used to provide
TCP/IP links over significant distances.  With the advent of V.32bis
modems, and with this software, another alternative exists.  It
appears to the application that the modems remain connected all the
time (like a leased line). In reality, however, they disconnect
whenever there is no traffic. When a packet to be transmitted arrives
at the interface, and the modems are not connected, a connection is
made and the packets begin to flow again.

1.2 Audience

This file contains information for those intending to install and use
dp (Dialup PPP), and is not aimed at teaching you about TCP/IP networking,
although subjects which may be new to you such as routing and nameservers
will be covered.

1.3 History

The base for this software is several other free packages that have
been modified to support this purpose.  The dialup code came from the
BBN Dialup Slip.  The PPP program is from Carnegie Mellon University. The
kernel PPP streams driver came from Brad K. Clements. The TCP/IP
header compression support came from Van Jacobson from the University
of California.  Kirk Smith at Purdue University assembled all these
pieces, made them all work together, and added a number of features
beyond the original software.

1.4 Release Notes

1.4.1 Supported Platforms

dp-2.X has been running on Solaris 1.X (SunOS 4.1.[123]) and works quite well.
It will probably not work on anything but Solaris 1.X. It
relies on STREAMS support.  It is possible to make it work in a
non-streams environment, but not easy.

dp-3.0 works on Solaris 2.X.  It has been tested on Solaris 2.1
and Solaris 2.2.  dp-3.0 does not work on Solaris 1.X (SunOS4.X).
Later versions should be compatible with Solaris 1.X.

1.5 Commercial Software

Companies sell products that do things similar to this.  I believe
that this software incorporates some unique features and has value in
itself. However, if you want a supported product, you might want to
shop around. Morning Star Technologies is one company that I know of.
Try sending mail to marketing@morningstar.com for more information. 
From what I can tell, they have a top notch product and top notch
support.

A mailing list "dplist@phoenix.acn.purdue.edu" is available.  To
subscribe to this list, send a message to
"dplist-request@phoenix.acn.purdue.edu". This list is a group of
people either using or thinking about using this software.

2. Operational Overview

The software known as Dialup PPP (or dp-3.0) consists of several
distinct modules.  This section will discuss how the modules fit
together and then will describe each module in more detail.

From the application standpoint, this software implements a network
interface.  Ethernet interfaces have names like ie0, le0, or le1,
etc. This interface has a name like dp0, dp1, dp2, etc.  While
ethernets are "Broadcast" networks, these are "Point to Point"
networks.  This is important to consider when dealing with address
assignment and routing. In short, when you "ifconfig" a point to
point interface, you must provide an IP address for both the source
and the destination.  Routes to the network never exist, but routes to
both ends of the interface may exist. For more information on this,
refer to the manual pages on ifconfig(8c), route(8c), and routed(8c).

This network is always "UP" from the perspective of "ifconfig". Under
normal conditions, network applications like "telnet" or "ftp" will
always see a network that is up, even if there is a slight delay
while modems are re-connecting.

2.1 File Location Configuration

Earlier versions of Dialup PPP placed files in very specific places.
dp-2.3 and later allows flexible placement of files.  The only really fixed
file is /etc/dp.conf.  It basically contains a list of pathnames
for all other files.  It looks like this:

	#
	# Config file for Dialup PPP.
	#
	# This file specifies the paths where all the related PPP files and
	# programs are located.
	#
	DPCONF_DIR=/etc/dp		 # System Specific Files
	DPLOG_DIR=/var/adm/dp		 # Log Files and Other Writeable Files
	DPPID_DIR=${DPLOG_DIR}/Pid	 # Files for Process IDs
	DPTRACE_DIR=${DPLOG_DIR}/Trace	 # Trace Files
	DPROTARY_DIR=${DPLOG_DIR}/Rotary # Rotary Files
	DPMUX_DIR=${DPLOG_DIR}/Mux	 # Streams Mux IDs
	DPID_DIR=${DPLOG_DIR}/Id	 # Module IDs
	DP_DIR=/opt/dp			 # Common Files for All Systems
	DPBIN_DIR=${DP_DIR}/bin		 # Programs
	DPSCRIPT_DIR=${DP_DIR}/script	 # Standard Dialing Scripts
	DPACCESS_DIR=${DP_DIR}/access	 # Standard Access Files
	DPAUX_DIR=${DP_DIR}/aux		 # Auxilliary Programs
	DPCRON_DIR=${DP_DIR}/cron	 # Scripts Run from Cron
	DPMODEM_DIR=${DP_DIR}/modem	 # Modem Support Programs
	DPMODULE_DIR=${DP_DIR}/modules	 # Kernel Modules

This file can be editted to put parts of the dp software in places that
make sense on the local system.

The DPCONF_DIR typically contains files that are specific to a given
system.  The "${DPCONF_DIR}/conf" file contains the bulk of the interface
configuration.  In addition, script and access files specific to a
single system can be placed in this directory.

The DPLOG_DIR contains log files and files that get written frequently.
It has a few subdirectories containing files that store current status.

The other directories should be about the same from one machine
to the next.  The default configuration file groups them all under ${DP_DIR}.
This can be changed to suit local needs. 

In the remainder of this document, we will refer to directories by their
symbolic name such as ${DPXXX_DIR} because the location can
vary from system to system.

2.2 Normal Operation

If the modems are connected, this network interface looks like a
dedicated leased line Point to Point interface.  Packets flow from the
kernel networking software to the appropriate "dp" device.  The kernel
driver for that interface consists primarily of the "dp" streams
multiplexing device driver.  The packets are streams messages and are
passed in turn to the "vjc" and the "pppasync" module. The vjc module
handles Van Jacobson compression, and the pppasync module encapsulates
the packets according to the PPP specification, including the addition
of a frame checksum.  It then passes the packets on to the streams
driver of the particular serial port hardware.  The serial hardware
passes the byte stream onto the modem and out into the public telephone
system.

In addition, packets can be sent from the user level PPP program
(called ppp). These packets are sent through the "dp" streams
multiplexing device, and then along the same path.

On the other end, incoming bytes are received by the serial port
streams driver and passed on to the "pppasync" streams module.  This
module collects the bytes together into packets and rejects packets
with bad checksums according to the PPP specification.  Then packets
are passed to the vjc module for possible header decompression.  Then,
packets are passed on to the "dpif" multiplexing streams driver where
they are identified by their PPP protocol and sent to the appropriate
upper level stream.  This could be the kernel IP stream or the user
level PPP control stream.

This series of modules basically multiplexes and demultiplexes packets
from the PPP programs and the kernel networking on both ends.

2.3 Establishing Modem Connections

Assume, for now, that the network is properly configured, and the
modems are not currently connected.  When packets arrive at the
interface to be transmitted to the other end, the dp device has no
lower stream attached.  There is no specific serial port associated
with the network interface at this time.  This corresponds to the
DISCON (disconnected) state.  The packet is placed in a network queue
awaiting a successful connection.

A copy of the packet is made with a special bit set in the protocol.
Valid PPP packets never have this bit set.  That packet is set upstream.
The input processing matches the protocol like any other packet,
and directs it to the user level dialing program (dpd).  Dpd has is
basically listening for packets with this special bit set in the protocol
field.  If no processing is listening for such packets, an error is
returned to the sending stream, with the UNIX error set to ENETDOWN.

When the "dpd" program is started, it reads the configuration file
"${DPCONF_DIR}/conf".  This contains information about each network
interface and each available modem.  For each interface, the dpd
program opens that device and listens for packets with the special bit
set.  So, when the request arrives, the "dpd" program checks for
authorization according to the interface configuration.  If a call is
not permitted, a FAILURE status is returned to the network interface.
Otherwise, dpd reports a CALL_IN_PROGRESS status and creates a child
process to handle this call.

An appropriate modem is selected according to the configuration (this
will be explained in more detail later), and the call is placed using
the appropriate dial script.  Once the call completes, the
appropriate login script is used to log into the remote computer.  A
special account is set up on the remote computer that uses the login
shell "${DPBIN_DIR}/dplogin". This program reads the configuration in
"${DPCONF_DIR}/conf", performs simple synchronization with the
"dpd" at the other end and sets the call status to CALL_IN_PROGRESS.

Both the "dpd" and "dplogin" programs start the "${DPBIN_DIR}/ppp"
program on both ends.  They negotiate all the options according to
their own configuration. Once they have completed their negotiations,
they report the SUCCESS call status and mark the network interfaces as
ACTIVE.

If a call FAILURE status is reported, or a call wait timeout expires,
the interface is marked with FAILEDCALL status.  After an appropriate
timeout, the interface moves back to a DISCON status.  This enforces
a minimum time between call attempts.  However, if the call failed
because no modem was available, dpd reports a special NO_MODEM status
which is similar to FAILURE status except the interface immediately
moves to the DISCON status so that further call attempts can be made.

2.4 Timing Out Modem Connections

Several timeouts can be specified in the configuration file
"${DPCONF_DIR}/conf".  Among those are the timeouts which govern
when the modems should be disconnected.  These timeouts are handled by
the kernel "dp" driver.  When the kernel decides to disconnect a given
interface, it sends a hangup signal (SIGHUP) to the "dp" process which
shuts down the link.  Due to problems in signal propagation, it
actually sends a specially defined DLPI packet that is interpreted as
equivalent to sending a signal.  The operation of each timer will be
described. Each timeout is given in seconds and is specified in the
configuration file. We have found that this particular combination of
timers is highly effective in our typical use.  It allows reasonable
timeouts for interactive use, while quickly timing out calls that were
made for batch operations.

2.4.1 Inactivity Timer

The simplest timeout mechanism is the inactivity timeout.  If no
packets have been sent or received within a given time interval, then
the modems are disconnected.  This is usually relatively long,
roughly on the order of 2 to 3 minutes.

2.4.2 TCP Close Timer

The kernel keeps track of TCP/IP connections.  Each TCP/IP connection
is characterized by a distinct source and destination address and
port. During the life of a TCP/IP connection, packets are exchanged
with certain bits set in the header to indicate the creation and
deletion of these logical connections.  The interesting parts of the
header are the SYN, FIN, and RST bits.  The software monitors the
TCP/IP connections in progress.  By noting the passage of SYN, FIN,
and RST bits in TCP/IP headers, we keep a count of the number of
active TCP/IP connections. When that connection count goes to zero,
we assume that everyone has finished using the network interface for
now, and a fast timeout is enabled. This shorter timeout will
disconnect the modems if no packets are sent or received over an
interval shorter than the normal inactivity timeouts. We have set
this interval as small as 5 seconds and it works quite well

2.4.3 Non TCP Timer

Not every network application uses TCP, so consideration is made for
that case.  A seperate inactivity timeout can be specified for non-TCP
traffic.  This is usually on the same order as the TCP Close timer,
but perhaps a little longer depending on the applications in use.

3. Source Code Overview

3.1 "conf" directory

This directory contains the /etc/dp.conf file and related files.
Before running make install, the dp.conf file should be edited as
appropriate for your system.

This directory also contains examples of ${DPCONF_DIR}/conf.  "conf.hub"
is an example of a central machine with several dp interfaces and
a few modems.  "conf.leaf" is an example of a machine with one dp interface
and one modem.  See section 5.3 for more information on this file.

The shell script "dpctl" is included in this directory.  This can
be used for starting, stopping, loading, unloading, reconfiguring, etc.
See section 6 for more information.

The dpconfig program is here as well.  This is used in order to configure
interfaces into the system at run time, and to do the equivalent of
"ifconfig dpX plumb".

3.2 "h" directory

This directory contains include files that are used by several of the
programs that comprise this distribution.

3.3 "dp" directory

This directory contains a slightly modified version of the CMU PPP
code. In release 2.0, it was based on "ppp" patch level 4, but under
release 2.3 and 3.0, it is based on "ppp" patch level 6.  This
will continue to be updated as new updates are made to the
standard ppp software.

The modifications to the standard PPP are small, but are necessary
for this mode of operation.  The "ppp" program takes all the flags
that apply to the standard "ppp" program.  In addition, if the "dialup" flag
is given to dp, it modifies the behavior in the following ways:

- The name of the network interface is dp0, dp1, etc., instead of
ppp0, ppp1, etc.

- When an interface is brought up, it executes a DPIOCCALLSTAT ioctl
which is specific to the dialup PPP software.

- When a normal PPP interface is brought down, it marks the network
interface as DOWN and removes the appropriate route.  For dialup PPP
interfaces, however, the interface always appears to be UP and the
route remains installed.

3.4 "dpd" directory

This is originally based on the diald program from BBN.  It has been
heavily modified to handle PPP rather than slip, and to handle the
different kernel interfaces.  This section will describe the major
differences in functionality.

The BBN code had a good expect script capability for doing the
dialing. This capability has been expanded somewhat to allow better
error handling. The "recv" directive has been modified to accept any
number of alternative strings.  One use this to accept all known
return codes from the modem. In addition, the timeout value on the
"recv" can now take on a value of 0. This means to only receive input
that has been already received when the "recv" is executed.  Use of a
"replay" followed by a "recv "string" 0" will immediately either succeed
or fail based on input received since the last "mark". An example of this
is the following:

    mark
    {
	alternate
	    recv "CONNECT" "BUSY" "NO CARRIER" 30
	alternate
	    log "Modem Timeout"
	    abort
    }
    {
	alternate
	    replay
	    recv "CONNECT" 0
	    go
	alternate
	    replay
	    recv "BUSY" 0
	    log "Busy"
	    abort
	alternate
	    replay
	    recv "NO CARRIER" 0
	    log "No Carrier"
	    abort
    }

This segment of a script will wait up to 30 seconds to accept either
"CONNECT", "BUSY", or "NO CARRIER", then immediately do the correct
branch.  This was impossible to handle in a timely way using the
original code.

The connection requests sent from the kernel to the "dpd" program
include more than just the IP header.  In fact, the whole packet is
usually transferred.  Future versions could screen on all sorts of
criteria if people feel the need.

The uucp locking conventions have been updated to match those in use
by the Sun version of uucp.  The Solaris 2.X version is quite different
from the Solaris 1.X version.  Both of them seem to handle things properly
with uucp and friends.  This is important to allow several programs to share
the available modems with the kernel networking.

A new flexible configuration file allows setting of many new options.
A later section devoted to this configuration file which will describe
the options in detail.

The timeout mechanisms have been expanded.  A "call wait" timeout is
supported for the maximum waiting period between a call request and
the completion of the call.  Once a call has failed, a "failed call"
timeout indicates the time to wait before initiating a new call. The
activity timeout is represented by one of 3 timeouts including
"inactivity", "tcp close", and "non tcp", representing the conditions
when TCP connections are active, no TCP connections are active, and
non TCP traffic is active.

The concept of a modem has been expanded to include a modem rotary. A
rotary is a group of modems that are used in a round robin fashion.
With a bank of modems and phone lines, there are basically two ways
to pick which modem to use next:  "first available" and "next
available". The "next available" option corresponds to a "rotary", a
round robin selection, and can be used in order to be more tolerant
of a single modem or phone failure.  Given modems 1 to N, if modem
number 1 fails, the "first available" selection will always fail and
the "next available" selection will fail 1 out of N times.

SunOS allows use of a single modem for both dial in and dial out
through the use of two minor device numbers for each port.  This
facility has been completely integrated into this software so that a
single port can be easily used for both incoming and outgoing calls.

A new program "dplogin" is included which shares a number of
functions with "dpd".  "dplogin" is used as a login shell for
incoming calls and uses the same configuration file as "dpd".  It
handles locking and logging in a compatible way.

A call log file is now generated for both incoming and outgoing
calls. Each line of the file corresponds to a successful call and
includes the following information: remote site name, tty device,
date and time of initiation of connection, total connect time,
initiating program (dpd or dplogin), protocol and port of initiating
request (like ip/tcp/smtp), and for both input and output, a report is
given of number of packets, bytes, and errors. The protocol and port
information is only available for outgoing calls.  This information
can be very useful for analyzing call patterns and minimizing costs.

An auxiliary program facility is provided.  If so configured,
whenever a modem connection is made, an auxiliary program can be
run.  This program could, for instance, check queues for outgoing
traffic and make use of the the connection to transfer mail, print
jobs, or other similar queued files. This could be easily tuned in a
site-specific way to reduce the number of calls needed by taking advantage
of connections already established.

3.5 "sys" directory

The sys directory includes the kernel modules, including the
following:

3.5.1 pppasync.c

The "pppasync" streams module, which packetizes data and does
PPP header compression.  It talks to the serial port module
below, and the "vjc" module above.

3.5.2 vjc.c

This is the Van Jacobson TCP header compression software that has
been incorporated into a streams driver.  It talks to the "pppasync"
module below, and talks to the lower half of the "dp" driver above.

3.5.3 dp.c

This file is a cloneable, modloadable, multiplexing streams driver.
It supports the DLPI (Data Link Provider Interface, Version 2.0).
It was written based on skeletal information, and currently, it
has problems being unloaded, but it seems to work well overall.

The connection status of each interface is handled and a number
of timeouts are implemented.  The timeouts include the following:

callwait:	time to wait for a call to complete
failedcall:	time to wait before trying another call
inactivity:	disconnect after no packets in A seconds.
tcp_close:	disconnect C seconds after last TCP connection is closed
		and no packets.
non_tcp:	disconnect U seconds after last non-TCP packet given no
		activity and no TCP connections.

The timeouts can be set from the dp configuration file.

The dp_activity function keeps track of TCP connections
in progress and will notice when all connections close and the line
can be disconnected using one of the "fast timeouts" (tcp_close or
non_tcp).

Included within dp_if.c is a driver for the "pppdial" streams device
that allows the kernel to request the initiation of calls from the
"dpd" program.

3.6 "dptrace" directory

Dptrace is a simple program that prints the request trace file.  As
each dialup request arrives through /dev/dp0, the dpd program writes
the current time and the current request to the file
"${DPLOG_DIR}/req.trace". This program reads that file and formats the
requests into a human-readable format. The program can be helpful in
debugging and tuning the network.

This program has not been modified to work under dp-3.0.

3.7 "modem" directory

This directory contains a program to set modem options on Hayes
compatible modems.  The "setmodem" command can be invoked as:

	setmodem [-v] scriptfile device [baud]

Scriptfile contains a number of AT commands that will be fed to the
modem. The setmodem program knows enough to expect OK returns from
the modem and waits until the OK to proceed to the next AT command.

Scripts for the telebit T1600, T3000, and WorldBlazer modems are provided
and have been tested.  You can modify these further to suit your configuration.

In addition, there is a shell script "initmodem.sh" which can be
invoked as:

	initmodem scriptfile outdev indev [baud]

The scriptfile is the same as in setmodem, and the outdev corresponds
to the device in setmodem, but the indev is the login side of the
same device that is given in /etc/ttytab.  This script first edits
/etc/ttytab to turn the login off for that port.  This allows
everything to work correctly with the softcarrier options, etc.  The
program resets the port before completion and generally is the preferred
way to handle the initialization of devices.

These scripts have not been modified to work under Solaris 2.X
Initialize the modems by hand..

3.8 "aux" directory

The aux directory contains the sources for auxiliary programs that
can be run when connections are established.  If so configured in the
"${DP_CONFDIR}/conf" file, whenever a modem connection is made,
an auxiliary program can be run.

Currently, the only program provided is a program called ckmailq.
This looks in the mail spool directory for outgoing mail that is not
currently being processed.  If such mail exists, it starts up
sendmail with the proper options.

Other similar programs could be written for other queued traffic such
as print jobs or uucp requests.  This can be used to "poll" for SMTP
mail when a remote site can't initiate calls on its own.

3.9 "access" directory

The access directory contains several example files for controlling
remote access and timeouts.  These are installed in "${DPACCESS_DIR}.

3.10 "script" directory

The script directory contains several dialing and login scripts.
These can be used as examples for your particular modems, etc.
These files are installed in ${DPSCRIPT_DIR}.

3.11 "cron" directory

The cron directory contains two shell programs (daily and monthly)
that can be run via crontab in order to keep the ${DPLOG_DIR} directory
from getting too large.  The file dp.crontab contains the two entries
that need to be manually entered into root's crontab in order for these
programs to be run via cron.


4. Building & Installation

This release does not support compiling modules into the kernel.
The loadable module support in SunOS is quite good, and this program
uses it.  In dp-3.0, unloading the "dp" driver does not work.  This
is typically not needed except in development.  The "vjc" and "pppasync"
modules will unload as they should.

4.1 Building & Installing

*	Uncompress and untar the distribution, which creates a directory
	called dp-3.0/

*	cd to dp-3.0

*	Edit Makefile.hw if you want support for 57,600 baud on Central
	Data Serial Ports.

*	Edit conf/dp.conf if there are any local places to put these
	things.  This is explained in section 5.1.

*	Type "make" and make sure there were no errors.

*	Become "root", and type "make install", which will create all the
	necessary directories and copy the files required across setting the
	correct ownerships and permissions.

4.2 System Files

A number of system files need site-specific entries added.
These files will be discussed here.

4.2.1 /etc/passwd

This procedure may vary slightly depending on the use of NIS or
shadow password files.  But, basically you will be defining users 
much like you would for a new system user.  Feel free to adapt
this procedure to your specific arrangement.

For each remote site that will be calling in, you need to create a login.
We have used the convention that PPP logins all start with the
letter 'P'.  This has made it easy to identify it as a "special" sort
of login when looking at the output of "who" or "finger".

Assume that we have 2 remote sites: "rem1" and "rem2".  We have
selected available user ids 601 and 602, respectively. 
Additionally, we have selected group id 1 (other) for these accounts.
Your choice may vary based on local convention.
"/etc/passwd" file entries would take the following form:

	Prem1:*:601:1:PPP Remote 1:/var/adm/dp:/opt/dp/bin/dplogin
	Prem2:*:602:1:PPP Remote 2:/var/adm/dp:/opt/dp/bin/dplogin

After creating these entries, we would use the command "passwd Prem1"
to set the password for the "Prem1" account, and similarly for
"Prem2".

4.3.4 /etc/hosts

In short, you need an entry in "/etc/hosts" for each "dp" interface.
Especially for PPP links with simple topologies, it is common to
reuse the same address as the internet address of your primary ethernet
interface.  If you are already in a subnetting environment, it is
preferable to dedicate one subnet to all the PPP links.  This makes
it easier to diagnose problems, since packets can be sent unambiguously
to the PPP interface.  Each PPP link is treated as a pair of IP
addresses.  A host route is installed in the two computers for
the address at the other end.  This takes precendence over network
routes.  To propagate this route, you may need to do more work.
Some possibilities will be explained later.

For broadcast networks, a network address is assigned for each
physical network. Host numbers are chosen for each host on the
network.  For an example class C addresses 199.10.11.14 and
199.10.11.52 are both on the same IP network (199.10.11). These
addresses represent hosts 14 and 52 on that network. IP routers know
how to get to the 199.12.11 network and pass packets on to the
appropriate gateway.  Once the packets get to that network, they are
then routed to host 14, 52, or whatever.

In contrast, the number of hosts on a Point to Point network is
always 2. So, in IP routing, we never actually use a route to the
network.  We just use a route to each individual address (both ends).
So, if we are administering several Point to Point networks, we can
use a single IP network, and assign pairs of addresses.  For
instance, assume we have a class C network 199.10.20 assigned for PPP
links.  Our first link could have the addresses 199.10.20.1 and
199.10.20.101.  Our second link could have the addresses 199.10.20.2
and 199.10.20.102.  We need two addresses for each link since we need
to assign an address to each end.  Using addresses differing by 100
for both ends of the link has proven to be a convenient convention
for us. It helps us to keep track of things when dealing with a large
central hub. 
So, let's say we have a hub machine called "hub", with 2 PPP links,
"dp0", and "dp1" serving the machines "rem1" and "rem2".  Each of
these remote machines has a single PPP interface "dp0".  Using the
addresses from the previous examples, we would have /etc/hosts
entries as follows:

	199.10.11.14	hub hub-le0
	199.10.20.101	hub hub-dp0
	199.10.20.102	hub hub-dp1
	199.10.20.1	rem1 rem1-dp0
	199.10.20.2	rem2 rem2-dp0

These are just guidelines and address assignment can be done in
different ways based on local conventions and local politics.  In
addition to the hosts file, many sites will also be using the DNS
(Domain Name System). The DNS files need updating to reflect the new
network addresses in a similar way.  In addition, routing can be
quite different based on the protocols involved.  For further
discussion about DNS and routing, see the later sections detailing a
sample configuration.

5.  Configuration

5.1. "/etc/dp.conf" file

Earlier versions of Dialup PPP placed files in very specific places.
dp-2.3 allows flexible placement of files.  The only really fixed
file is /etc/dp.conf.  It basically contains a list of pathnames
for all of the other files.  It looks like this:

Solaris 2.X version:
	#
	# Config file for Dialup PPP.
	#
	# This file specifies the paths where all the related PPP files and
	# programs are located.
	#
	DPCONF_DIR=/etc/dp		 # System Specific Files
	DPLOG_DIR=/var/adm/dp		 # Log Files and Other Writeable Files
	DPPID_DIR=${DPLOG_DIR}/Pid	 # Files for Process IDs
	DPTRACE_DIR=${DPLOG_DIR}/Trace	 # Trace Files
	DPROTARY_DIR=${DPLOG_DIR}/Rotary # Rotary Files
	DPMUX_DIR=${DPLOG_DIR}/Mux	 # Streams Mux IDs
	DPID_DIR=${DPLOG_DIR}/Id	 # Module IDs
	DP_DIR=/opt/dp			 # Common Files for All Systems
	DPBIN_DIR=${DP_DIR}/bin		 # Programs
	DPSCRIPT_DIR=${DP_DIR}/script	 # Standard Dialing Scripts
	DPACCESS_DIR=${DP_DIR}/access	 # Standard Access Files
	DPAUX_DIR=${DP_DIR}/aux		 # Auxilliary Programs
	DPCRON_DIR=${DP_DIR}/cron	 # Scripts Run from Cron
	DPMODEM_DIR=${DP_DIR}/modem	 # Modem Support Programs
	DPMODULE_DIR=${DP_DIR}/modules	 # Kernel Modules

Solaris 1.X version
	#
	# Config file for Dialup PPP.
	#
	# This file specifies the paths where all the related PPP files and
	# programs are located.
	#
	DPCONF_DIR=/etc/dp		 # System Specific Files
	DPLOG_DIR=/var/adm/dp		 # Log Files and Other Writeable Files
	DPPID_DIR=${DPLOG_DIR}/Pid	 # Files for Process IDs
	DPTRACE_DIR=${DPLOG_DIR}/Trace	 # Trace Files
	DPROTARY_DIR=${DPLOG_DIR}/Rotary # Rotary Files
	DPMUX_DIR=${DPLOG_DIR}/Mux	 # Streams Mux IDs
	DPID_DIR=${DPLOG_DIR}/Id	 # Module IDs
	DP_DIR=/usr/dp			 # Common Files for All Systems
	DPBIN_DIR=${DP_DIR}/bin		 # Programs
	DPSCRIPT_DIR=${DP_DIR}/script	 # Standard Dialing Scripts
	DPACCESS_DIR=${DP_DIR}/access	 # Standard Access Files
	DPAUX_DIR=${DP_DIR}/aux		 # Auxilliary Programs
	DPCRON_DIR=${DP_DIR}/cron	 # Scripts Run from Cron
	DPMODEM_DIR=${DP_DIR}/modem	 # Modem Support Programs
	DPMODULE_DIR=${DP_DIR}/modules	 # Kernel Modules

The DPCONF_DIR typically contains files that are specific to a given
system.  The "${DPCONF_DIR}/conf" file contains the bulk of the interface
configuration.  In addition, script and access files specific to a
single system can be placed in this directory.

The DPLOG_DIR contains log files and files that get written frequently.

The other directories should be relatively static from one machine
to the next.  The default configuration file groups them all under ${DP_DIR}.
This can be changed to suit local needs. 

5.2  "${DPCONF_DIR}/hostnames" file

This file should contain a list of all the dp interfaces and include
the local and remote inernet address used on the interface.

If you have 3 interfaces, and all of them have the same local IP address,
and you have 3 remote sites with (necessarily) unique addresses, the
file would look like this:

	dp0 local-dp remote0-dp
	dp1 local-dp remote1-dp
	dp2 local-dp remote2-dp

5.3  "${DPCONF_DIR}/conf" file

When, the programs "dpd" and "dplogin" are started, they read a
configuration file "${DPCONF_DIR}/conf".  This file has a
definition for each interface, each modem, and optionally a number of
modem rotaries.

A definition begins in the first column of a new line.
Continuation lines must begin with white space (SPACE or TAB
characters). Comments can be placed anywhere in a line after
a #. Strings can be delimited by double quote characters (""),
if necessary.

For a given definition, each variable is given a value with the
variable name, an equal sign, and the value.  For instance, the first
entry in the definition for the dp0 interface is:

	IF=dp0

This section defines all the possible options, their possible values,
and gives some examples to show how they might be used.

5.3.1  Interfaces

Each interface corresponds to a logical network connection to a
single remote site.  Provisions are made in the interface definition
to specify how calls should be made and received in order to handle
traffic on that interface.

5.3.1.1  IF

The IF variable must be the first entry in the interface definition.
Its value is the name of the network interface (e.g. IF=dp0).

5.3.1.2  SYS

The SYS variable can be optionally set to indicate a system name to
be used when making log entries.  If the SYS variable is not
explicitly set, it defaults to the internet name of the remote site
(as returned by gethostbyaddr()), or if that fails, the internet
address of the remote site in dot notation.

5.3.1.3  MODEMS

The MODEMS variable specifies the modems or modem rotaries that
should be used to make calls for this interface.  At least one modem
or modem rotary must be specified.  If more than one modem or modem
rotary is specified, when a call request is made, each entry in the
list is tried in turn until an available modem is found.  The names
used in this list must correspond to a MODEM or ROTARY definition as
specified in the configuration file.

5.3.1.4  PHONE

The PHONE variable specifies the phone number that will be passed to
the DIAL_SCRIPT as defined by the modem in use on a particular call.

5.3.1.5  LOGIN_SCRIPT

The LOGIN_SCRIPT variable specifies an expect script that will be
used to log into the remote system for the purposes of establishing a
PPP connection. These scripts are found, by default, in
${DPSCRIPT_DIR} and will be described in detail later.
Scripts specific to a single system can also be placed in ${DPCONF_DIR}.

5.3.1.6  LOGIN_ARGS

The LOGIN_ARGS variable is a comma-separated list of arguments to the
expect script as defined by the value of LOGIN_SCRIPT.  This is
typically the login and password on the remote machine.

5.3.1.7  LOGIN

The LOGIN variable has practically nothing to do with the
LOGIN_SCRIPT and LOGIN_ARGS variables, both of which deal with
outgoing calls.  The LOGIN variable, instead, is set to allow a
particular login id to be used to call in to establish a PPP
connection.  When dplogin is called, it knows what account was used
to log into the system.  It searches the configuration file for an
interface where the LOGIN variable is set to that same account.

5.3.1.8  TRACE

The TRACE variable can be used to specify a trace file for the
calling script.  The trace files are written in ${DPTRACE_DIR}.
If there is a problem with establishing a particular connection,
this variable can be set to see what characters are being
transferred when the DIAL_SCRIPT and LOGIN_SCRIPT are both run.

5.3.1.9  ACCESS

An ACCESS file can be specified.  This file defines a number of
additional variables and can be used to limit the conditions for
which calls will be made.  This file is located, by default, in the
${DPACCESS_DIR} directory. Access files local to a single system can
be placed in the ${DPCONF_DIR}. This file will be described in detail in
the next section.

5.3.1.10  PPP_ARGS

When the PPP program "${DPBIN_DIR}/ppp" is started by dpd or dplogin, you can
specify additional arguments to be put in the argument list.  For
instance, if you are using dp.2.3 to talk to a dp.2.0 installation,
the default header compression negotiation has changed with the new
patch level of PPP. So, in the 2.3 configuration file, you can put
the line:

	PPP_ARGS=vjmode,old

This will talk to a patchlevel 4 PPP correctly and the option negotiation
will function properly.

5.3.1.11  AUX

The AUX variable specifies an auxiliary program that will be run
after a PPP link is established for a particular interface.  The
default location for these programs is ${DPAUX_DIR}.  An example
program is provided that checks the sendmail queue for queued
messages.  This could be run to make sure mail messages are sent out
whenever the link is established for any reason.

5.3.1.12  AUX_ARGS

Arguments may be provided to AUX program by specifying them here as
a comma separated list of arguments, much like the PPP_ARGS variable.
The last argument provided to the AUX script is always the system name
from the SYS variable.

5.3.1.13  LOG_LEVEL

The Log Level can be set when dpd is started.  The LOG_LEVEL variable
overides the current log level for calls made to this system.  In addition,
dplogin will set the same LOG_LEVEL for incoming calls.

5.3.1.14  ASYNC_MAP

The PPP program can be setup to avoid using certain control characters on
links that aren't totally transparent.  This takes the form of
a 8 digit hexadecimal string representing a 32 bit number.  The lowest
to highest order bits of the number correspond to the ASCII character
represented by 0 through 31.  If the bit is set, that character will
not be transmitted on the line, but will instead be replaced by a special
escape sequence.  By default, the ASYNC_MAP is set to 0, which means pass
all characters since we have a totally transparent link.  This variable
applies to all calls made to this system on any device.

5.3.2  Modems

A modem entry is required for each serial device that can be used to
establish a connection to a remote system.

5.3.2.1  MODEM

The MODEM variable must be the first entry in the modem definition.
Its value is an arbitrary (hopefully descriptive) name.  This same
name is used in the interface definition as a value for the MODEMS
variable.

5.3.2.2  DEV

The DEV variable is set to the physical serial device path name.
If the entry does not begin with a "/", then it is assumed that the
device appears in the "/dev" directory.  Sun has a scheme for using
the same line for dial out and dial in.  For most configurations, you
should use the name of the dial out device.  This is the one with the
0x80 bit set in the minor number. If necessary, you can make the
dialout device for a given login port. As an example, assume we are
using "ttya" and we want to make a dialout device "cua0". Here are
some example commands run as root to make the device.

	# ls -lg /dev/ttya
	crw--w--w-  1 root     wheel     12,   0 May 21 12:30 /dev/ttya
	# /etc/mknod /dev/cua0 c 12 128
	# chmod 660 /dev/cua0
	# /etc/chown uucp.uucp /dev/cua0
	# ls -lg /dev/ttya /dev/cua0
	crw--w--w-  1 root     wheel     12,   0 May 21 12:30 /dev/ttya
	crw-rw----  1 uucp     uucp      12, 128 May 21 12:30 /dev/cua0

Then, you would put "DEV=cua0" in your modem definitions to use this
device.

5.3.2.3  DIAL_SCRIPT

The DIAL_SCRIPT variable is the name of a script file.  The directories
${DPCONF_DIR} and ${DPSCRIPT_DIR} are searched for these files.
By convention, common scripts are placed in ${DPSCRIPT_DIR} while
system-specific scripts are placed in ${DPCONF_DIR}.  This script
will be used to interact with the modem and make the call.  The phone
number is passed as the first and only argument to the script.

The next section describes modem rotaries.  If all the modems in a
rotary use the same DIAL_SCRIPT, it is not necessary to set each one
individually.  The DIAL_SCRIPT variable is set from the ROTARY
definition.

5.3.2.4  BAUD

The BAUD variable is the baud rate to use for outgoing calls on this
modem.

The next section describes modem rotaries.  If all the modems in a
rotary use the same baud rate, it is not necessary to set each one
individually.  The BAUD variable is set from the ROTARY definition.

5.3.2.5  DIAL_CHARMAP

This variable is set in order to map characters embedded in phone numbers
to the appropriate modem-specific control character.  For instance, it may
be a common practice to include a '=' in phone numbers when you have to
wait for a secondary dial tone and a '-' when you just have to pause for
a second.  For Telebit modems, then the remapping would be performed with:

    DIAL_CHARMAP==W-,

which means wait for dial tone is 'W', and a short pause is ','.
This allows modems of different brands to be used without undue
difficulty.

5.3.2.6  ASYNC_MAP

The PPP program can be setup to avoid using certain control characters on
links that aren't totally transparent.  This takes the form of
a 8 digit hexadecimal string representing a 32 bit number.  The lowest
to highest order bits of the number correspond to the ASCII character
represented by 0 through 31.  If the bit is set, that character will
not be transmitted on the line, but will instead be replaced by a special
escape sequence.  By default, the ASYNC_MAP is set to 0, which means pass
all characters since we have a totally transparent link.  This variable
applies to all calls made with this specific modem.

5.3.3  Modem Rotaries

If you are administering a central hub machine with several modems,
you may wish to define a modem rotary.  When defining the interfaces,
you can set the modem variable to a list of modems (or rotaries). 
Each one will be tried in turn until an available modem if found. 
For a large number of modems, this is not very tolerant to hardware
failures.  If the first modem in the list is broken, calls will
always fail.  This approach is sometimes called using the "first
available" modem.

An alternative approach is to define modem rotaries.   A rotary is
best described as a "next available" approach.  The software keeps
track of the last modem used, and always starts with the next modem
in the list.  When the end of the list is reached, the search wraps
aournd to the first modem. This reduces overhead of finding a free modem
and insures that a bad modem will not totally shut down communications.

5.3.3.1  ROTARY

The ROTARY variable must be the first entry in the modem definition.
Its value is an arbitrary (hopefully descriptive) name.  This same
name is used in the interface definition as a value for the MODEMS
variable. Modems and rotaries can both be listed in the MODEMS
variable equally well.

5.3.3.2  MODEMS

The MODEMS variable is set to a comma-separated list of one or more
modems. The entries in the list are the names of the modems as
defined by their MODEM variable.  All entries in this list must be
modems.  Other rotaries cannot be used here.

5.3.3.3  DIAL_SCRIPT

The DIAL_SCRIPT variable is the name of a script file.  The directories
${DPCONF_DIR} and ${DPSCRIPT_DIR} are searched for these files.
By convention, common scripts are placed in ${DPSCRIPT_DIR} while
scripts specific to single systems are placed in ${DPCONF_DIR}.
This script will be used to interact with the modem and make the call.
The phone number is passed as the first and only argument to the script.

This entry will be used if the MODEM definition does not define a
DIAL_SCRIPT itself.  This is useful when a pool of modems are all the
same type and the DIAL_SCRIPT is the same for all of them.

5.3.3.4  BAUD

The BAUD variable is the baud rate to use for outgoing calls on any
modem in this rotary.

This entry will be used if the MODEM definition does not define a
BAUD itself.  This is useful when a pool of modems are all the same
type and the baudrate is the same for all of them.

5.3.3.5  DIAL_CHARMAP

This variable can be set here instead of in the MODEM definition.
If all the modems in a rotary are of the same brand, it is convenient
to set this variable in the ROTARY definition rather than setting it
in each MODEM definition.

5.3.3.6  ASYNC_MAP

This variable can be set here instead of in the MODEM definition, and
then applies to all calls made with any modem in this rotary.  If all the
modems in a rotary are of the same brand, it is convenient to set this
variable in the rotary definition rather than setting it in each modem
definition.

5.4  Access Files

An access file can be defined to describe the conditions when a call
is permitted and to set the timeouts appropriately.  For instance, if
you have some sites that are long distance toll calls, and some that
are local calls, you may wish to have shorter timeouts on the toll
calls than on the locals.

The format of the access came from the BBN DialupIP software.  It has
been expanded in several ways, but it still looks pretty similar.
Aside from several small changes in the existing options, a series
of timeout specifications has been added.

5.4.1 Timeouts

There are eight timeouts which can be specified, three that can
be set separately for incoming and outgoing calls, and 2 more that only
make sense for outgoing calls.  Here is a sample section from a access
file showing all 8 timeouts:

    #
    # Connection Timeouts (all times in seconds)
    #
    failedcall		 25	# time to mark network as down after failed call
    callwait		 50	# time to allow for call to go through
    #
    # Activity Timeouts
    #
    dial:inactivity	180	# time to let the connection sit idle
    dial:last_close	  6	# fast timeout after last TCP close
    dial:non_tcp	 10	# fast timeout for non-TCP traffic
    answer:inactivity	600	# time to let the connection sit idle
    answer:last_close	180	# fast timeout after last TCP close
    answer:non_tcp	180	# fast timeout for non-TCP traffic

Since we are paying for outgoing calls made, we set short timers so
that disconnections are prompt.  For incoming calls, we set some
limits just to keep the modem pool from being tied up.

5.4.1.1 Callwait

When the kernel "dpif" module requests a call be placed by "dpd", the
kernel starts the call wait timer.  If no status has been reported from "dpd"
within "Callwait" seconds, it is equivalent to receiving a "FAILURE" status
from "dpd".

5.4.1.2 Failedcall

After a FAILURE status or after the expiration of the Callwait timer,
the interface is marked with the FAILEDCALL status.  With that status
set, no calls will be attempted.  After "Failedcall" seconds, the interface
status is marked as DISCON, and call attempts will again be made.

5.4.1.3 Inactivity

If no packets have been sent or received through a PPP interface within
"Inactivity" seconds, PPP is terminated and the interface is marked as DISCON.

5.4.1.4 Tcp_close

TCP packets contain information about connections starting and ending.
A count of active connections is maintained for each interface.  When
this count goes to zero, if no packets have been sent or received within
"Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON.

5.4.1.5 Non_tcp

When the active TCP connection count goes to zero, and non-TCP packets
are being transmitted, if no packets have been sent or received within
"Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON.

5.4.2 Protocols

We can limit the calls made by the protocol.  Here is a sample access
file entry that would only allow tcp, udp, and icmp packets:

	protocols	tcp udp icmp

The keyword "goodprotocols" can be used in place of "protocols".
In addition, the keyword "badprotocols" can be used to disallow calls
based on certain protocols.

Any protocol that is in the "/etc/protocols" file is a valid entry on this
line.  Please note that this only controls the initiation of a call request.
Once a call succeeds, other protocols can be transmitted.

5.4.3 Times

By default, calls can be placed at any time.  If you wish to limit calls
during certain hours of certain days, you can place entries in the access
files containing the day and the hours when calls are should not be permitted.
The specifiable days are:

	sun	sunday
	mon	monday
	tue	tuesday
	wed	wednesday
	thu	thursday
	fri	friday
	sat	saturday
	weekdays
	weekends

For instance, if calls should only be allowed during "business" hours of
monday through friday (8-5), with no calls in the evening or weekends,
you would use the following entries:
	
	weekdays	0 1 2 3 4 5 6 7 17 18 19 20 21 22 23 24
	weekends	0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

If a day is not mentioned either explicitly or via the weekday/weekend
keyword, then calls can be placed all day.

To allow calls only during times with lower rates, one might want to turn
off calls during the 8-5 business day.  This would be done with the following
line:

	weekdays	8 9 10 11 12 13 14 15 16

Calls would then be placed anytime before 8AM and after 5PM on weekdays
and any time on weekends.

5.4.4 Hosts/Networks

To limit calls when certain hosts are involved, you can use further keywords.

In order to limit calls to packets which are destined to a list of specific
hosts, you would use the "allowto" (or equivalently "gooddstaddresses")
keyword.  If the access file has a line of this form, a call will fail for
packets having destination addresses not in this list.  So, if we wish
calls to be placed for only hosts on the 192.100.10.0 network and the
goodhost.com host, a line of the following form would be used:

	allowto	192.100.10.0 goodhost.com

In order to limit where a packet may come from, you can use the "disallowfrom"
(or equivalently "badsrcaddresses") keyword.  If a call request is made
for a packet coming from an address in this list, then the call fails.
An example would be

	disallowfrom	badhost.edu

The addresses given in these lists can be the name of a network, the
name of a host, or equivalently an internet host or network address in
dot notation.

5.5  Script Files

The script mechanism is used by the dpd program to interact with modems
and systems to make calls and log in to remote computers.  It provides a
full send-expect style facility, with many extensions to allow for
timeouts, alternative choices and others.  This is a direct extension
of the DialupIP 2.0 script file mechanism with the following additions:

- Two separate scripts are required for dialing and for login.

- Timeouts can be 0 to indicate matches of previously received data (via a
  mark/replay command pair).

- "recv" commands can match more than one alternative string

Script files contain a sequence of lines, each with a command and zero or
more arguments.  Blank lines and lines beginning with # are ignored.
Strings must be quoted with double quotes (") if they contain white space.
Standard C escape sequences are valid (\b, \f, \n, \r, \t, or \000 where 000
is any octal number).

Several example script files are provided in the distribution for dialing
several different Telebit modems directly into a remote system as follows:

t1600-dial	Dials the given number on a Telebit T1600 modem.
t3000-dial	Dials the given number on a Telebit T3000 modem.
wb-dial		Dials the given number on a Telebit WorldBlazer modem.
ppp-login	Logs into a remote system directly.  The first argument
		is a login, and the second argument is the password.
		This assumes the login shell on the remote system is "dplogin",
		and performs simple synchronization with that program.

You may note that the t3000 and Worlblazer scripts are the same since we use
V.32bis in both cases.  For PEP usage, the WorldBlazer script will
need to be modified to handle additional CONNECT messages.

5.5.1 abort

The "abort" command terminates the script with a failure code returned.
Reading the script past the end of file is equivalent to the "abort" command.

5.5.2 go

The "go" command indicates success.  For a dial script, success means
that the call went through using the specific modem.  For a login script,
success means that PPP is started on the remote computer.

5.5.3 log "text"

This writes the given string to the log file (${DPLOG_DIR}/dp.log).

5.5.4 mark

As incoming bytes are received, they are saved in a buffer for possible later
use by "replay".  The mark command indicates the beginning of where to start
saving characters.

5.5.5 replay

Characters in the incoming buffer are replayed as if they are being received
again.  This replay starts at the most recent mark command.

5.5.6 recv "text" [ "text" ... ] timeout

The recv command is used to examine the incoming characters (which can be
actual new characters, or older ones after a replay command.  The command
succeeds when a substring of the incoming characters matches one of the
"text" patterns given.  If the match has not succeeded in "timeout" seconds,
the "recv" command returns failure.  However, if the "recv" command is in
a "select block", control is passed to the next alternative.

5.5.7 use script [ "parameter" ... ]

The use command executes another script file and returns success or failure
depending on the execution of the named script.

5.5.8 xmit "text"

This sends the indicated text to the remote system.  A \x in the string
will delay 1 second, and a \# will send a break.
Also, the string $1 will be replaced by the first argument to the script,
and so on.  The arguments are given in the dp-conf file or as arguments
to the "use" command.

5.5.9 Select Blocks

Select blocks allow you to specify alternatives on failure of specific
"recv" commands.

The format is as follows:

    {
	alternate
	    commands...
	alternate
	    commands...
    }

The "{", "}", and "alternate" keywords are commands and must be on separate
lines.  If a "recv" command fails, then control is passed to the next
alternate.  If all alternatives fail, then the select block returns a
failure, and is equivalent to an "abort".

6. Operation

Once configured, operation should be pretty automatic.  Should you need
to reconfigure while the system is up, the dpctl command will be useful.
Here are the possible arguments of the "/etc/dpctl" command:

    Options for controlling dpd
	-s	Start dpd
	-h	Send HUP signal to dpd to re-read ${DPCONF_DIR}/conf
	-k	Kill dpd
	-r	Kill, then start dpd (restart after installing new version)

    Options for system network configuration
	-c	Configure interfaces (from ${DPCONF_DIR}/hostnames)

    Options for dealing with device drivers
	-l	Load device drivers (not necessary under Solaris 2.X)
	-u	Unload device drivers (before installing new version)

7.  Routing

There are two ways, in general, that you will connect systems
together with dp. The first is a single machine (typically at home)
to a network of systems (the office network or maybe the Internet)
and second to connect two networks (two sites for example, or an
office network to the Internet).

In either case, the networking software has to know how to get to the
"other" systems. This is done in the kernel by routing tables. There
is at least one route to each interface, but the administrator (you)
can add more.

7.1 Static Routing

Where there is a single machine and a remote network or two
reasonably stable networks which are under your administrative
control, then the simplest way of setting things up is to use static
routes.

Again, in the Unix way there is always more than one way of doing
things, and this is true for installing route into the kernel. 

7.1.1 "route"

The most direct way to install a new route is the use the route(8)
command. "route" will allow you, as superuser, to add and delete
routes in the kernel. There are three (really two) types of route:

Route to a Host
    This type of route effectively says: you can get to this host via
    this interface.

Route to a Network
    This type says there is a network over there, past that interface
    on the left :-)

The Default Route
    The is a special route that is used as a catch all. It is most
    useful for a single host (home) connecting to everything else and
    tells the networking software to route everything down a single
    line if the is no other explicit route for it.

As an example, let's say that a home system is connected to a work system
via a PPP link.  "home.com" has the PPP interface of 192.220.10.1
"work.com" has the PPP interface 192.220.10.2 and the ethernet interface
192.220.11.18.  In order for another machine on the work ethernet to get to
the home system, it would need the command
	
	/usr/etc/route add 192.220.10.1 192.220.11.18 1

In order for the home system to reach other hosts on the work ethernet,
it would need the command:

	/usr/etc/route add 192.220.11.0 192.220.10.2 1

Assume now that the ethernet is connected to other networks or the Internet.
Then, the best command for home.com would be:

	/usr/etc/route add default 192.220.10.2 1

This would route all remote packets through the PPP interface.

7.1.2 Proxy ARP

Proxy ARP is a possibility in simple configurations.  A proxy ARP daemon
called "parpd" is available that will make the machine on the
other end of the PPP interface look like it is on the local ethernet.
In this case, an IP address on the local subnet must be used for the
remote system, and the Proxy ARP daemon will respond to ARP request on
the local ethernet as a proxy to the remote host.  This is probably
the simplest way to handle the simple case of one remote machine.

7.1.3 "/etc/gateways"

The other method is to create a file called "/etc/gateways" that
lists static routes to be made available when the routing daemon is
started during boot.

This file is read when "in.routed" is started in "/etc/rc.local".
For further information, see the routed(8c) manual page.


7.2 Dynamic Routing

In the case where two networks are connected, and these may have
further connections added to them or taken away,  then there must be
a way for the routing information to be updated at regular intervals
so that packets can get to their intended destinations.

7.2.1 Routed

Routed(8c) has been used extensively for adapting routes to changing network
connectivity.  It will work in this case of PPP links.  Routed works by sending
RIP packets (Routing Information Protocol) on every interface every 30 seconds.
Clearly, if we wish to disconnect the phone when our interface is not in use,
this will cause problems.  For this reason, routed is probably not the best
choice for routing on hosts with dialup PPP interfaces, unless the intent
is to keep the phones connected all the time.

7.2.2 Gated

Gated is a program that knows about routing via several protocols.
It can handle RIP (routed) packets, as well as other protocols such
as EGP (External Gateway Protocol) and GGP (Gateway to Gateway Protocol).
It also can be used to consider certain routes as "static" and to be always
available.  These routes can then be advertised using any of the available
routing protocols, including RIP.

If you have RIP based routing, then gated can be easily set up on your
hub machine up to use static routing for the PPP links and use RIP for
the other (ethernet?) networks.

Here is an example gated configuration file for our campus hub that talks
to 6 remote systems, each with a local ethernet at the other end:

    #
    #	Config file gated on phoenix.acn.purdue.edu
    #
    traceoptions internal external route rip update ;
    #tracefile "/tmp/gated.trace" ;

    interface all passive ;		# don't time out my interfaces!

    #
    # Do rip except on the PPP interfaces
    #
    rip supplier {
	interface dp0 noripout noripin ;
	interface dp1 noripout noripin ;
	interface dp2 noripout noripin ;
	interface dp3 noripout noripin ;
	interface dp4 noripout noripin ;
	interface dp5 noripout noripin ;
    } ;

    #
    # Set up static routes to remote ethernets at the end of PPP links
    # We are advertising ourself as a gateway to the subnetwork assigned
    # to the PPP links.  For each remote ethernet, the remote end of a PPP
    # link is being advertised as a gateway.
    #
    static {
	128.46.177.0 gateway 128.46.157.167 ;	# PPP Links
	128.46.34.0  gateway 128.46.177.34 ;	# Remote ethernet
	128.46.181.0 gateway 128.46.177.43 ;	# Remote ethernet
	128.46.176.0 gateway 128.46.177.49 ;	# Remote ethernet
	128.46.182.0 gateway 128.46.177.50 ;	# Remote ethernet
	128.46.84.0  gateway 128.46.177.84 ;	# Remote ethernet
    } ;

    #
    # Send out all sorts of interesting information in RIP packets
    #
    propagate proto rip {
	#
	# Propagate anything learned via RIP
	#
	proto rip ;
	#
	# Propagate static routes to county ethernets
	# Technically, the metric for remote ethernets should be 2,
	# but 1 works better in this scenario since there are no alternate
	# routes anyway, especially direct routes.
	#
	proto static metric 1 ;
	#
	# Propagate routes to all connected interfaces
	#
	# proto direct metric 1 ;
    } ;

    #
    # We don't have SNMP configured in
    #
    #snmp no ;

We are using gated 2.1 and it is available via anonymous ftp from
gated.cornell.edu in the file "pub/gated/gated/gated.tar.Z".
It works quite well in our configuration.


7. Tuning

You need to set up your "${DPCONF_DIR}/conf" file and any script
and access files for what makes sense in your environment.  The primary
tuning comes in getting your dialing scripts to work, selecting appropriate
timeouts in your access file, and monitoring what happens.

The file ${DPLOG_DIR}/call.log can be used to give you a one line
summary of each successful call.  The file ${DPLOG_DIR}/dp.log can be used
to show you a blow by blow description of calls in progress.  The amount
of logging can be increased by invoking dpd with "-d N" where N can be anywhere
from 0 for minimal logging to 3 for verbose logging.  In addition, the log
level can be set for individual systems in the configuration file.

If you encounter problems with the kernel modules, you can turn on very
verbose debugging output by setting the following kernel variables:

dp streams driver	    (dp.o)
    dp_debug			General info
    dp_debug_dump_msg		Print trace of packets
    dp_debug_lists		Print linked lists after updates

vjc streams module	    (vjc.o)
    vjc_debug			General info

pppasync streams module	    (ppp_async.o)
    ppp_async_debug		General info
    ppp_async_input_debug	input packet dump of N bytes

These variables are all "int" variables and should be set to 0 or 1, to have
the reporting off or on, respectively.  The ppp_async_input_debug variable
can be given a value greater than 1 to indicate the number of bytes printed in
a packet trace.

When running adb on the kernel, you must be sure to specify the correct
object file so that you get the correct symbols.  Under Solaris 1.X,
you must link a new object file using the "mksyms" shell script in
the sys directory.  This will create a file called vmunix.syms that
can be used as an object file.  Under Solaris 2.X, the kernel already
provides access to all loaded symbols via the device "/dev/ksyms".

Here is a typical adb session:

    # adb -w -k /dev/ksyms /dev/mem
    physmem fe9
    ppp_async_input_debug/X
    _ppp_async_input_debug:	0
    /W0t32
    _ppp_async_input_debug:	0x0	=	0x20
    $q
    #

In order to set a variable to remain in effect after the next reboot,
you must adb the individual module files. Under Solaris 2.X, these are
located in

	/usr/kernel/drv/dp
	/usr/kernel/strmod/vjc
	/usr/kernel/strmod/pppasync

7.1 Broadcast programs

Some programs broadcast information on a regular basis to all connected
interfaces.  If a program is found to generate frequent output on PPP
interfaces, it should be reconfigured, modified, or just not run at all,
depending on the circumstances.

7.1.1 rwhod

A common example of a talkative program is rwhod.  If you must run rwhod,
it should be modified to ignore PPP links.  Context diffs for rwhod are
available on phoenix.acn.purdue.edu in pub/rwhod.diffs.Z.  Once applying
these diffs to rwhod sources, you should be able to run rwhod with the
"-p" flag to suppress all output on Point to Point interfaces.

7.2 Nameserver

If you are on the Internet, you are basically mandated to use DNS.
If you are relying solely on DNS (no NIS or host tables), you should
set up nameservers at the remote sites. Care should be taken in the
configuration of the nameservers.  There are at least a couple of ways
that you can set things up.

7.2.1 Secondary nameservers 

You can set up secondary nameservers on each of the remote sites.
They can zone load your organization-wide zones on a regular basis.
Please note that zones have a refresh time at which point a connection
will be made to check for updates.  This can vary, but it may be 12 hours
or so.  This interval is specified in the zone file on the primary nameserver.
At this interval, the remote secondary nameserver will contact the primary
nameserver (generating a call in our case).  It will verify that the primary
has the most recent version of each zone of interest.

7.2.2 Primary nameservers

For remote sites that are placing toll calls, a refresh interval of 12
hours would result in 2 extra toll calls per day.  This may be a problem.
If so, consider making the remote system a primary nameserver.  When the
central nameserver file is updated, it needs to be distributed to all remote
primary nameservers, but this may be preferable compared to all the long
distance toll charges of the more automatic scheme employed by the secondary
nameservers.

In general the remote primary servers should not be listed in the
nameserver data contained in the zone data.  Otherwise, distant Internet hosts
may try to use them for information about the zone, generating unnecessary
traffic.  They should exist as primary nameservers, but not be advertised
as such.

8. Supporting Higher Baud Rates

This software includes support for baud rates greater than 38400 in
a few special circumstances.

8.1 Sun zs Ports

The zs ports on the Suns are capable of going faster than 38400. The
divisor in the hardware timer chip is set so that

    baud_rate = 4915200 / ((divisor + 2) * 2 * 16)

Here are some example divisors

      Divisor	Baud Rate
	510	   300
	62	  2400
	14	  9600
	6	 19200
	2	 38400
	1	 51200
	0	 76800

So, there is a little room for going faster.  Unfortunately, there is
not a 57600 baud rate available.  However, some modems can handle 76800
(such as the Telebit Worldblazer), and that can be set just as easily.
By default, the "-DFASTSZ" flag is set in the Makefile.hw file.
So, code will be compiled into the program that will recognize
76800 as a valid baud rate.  Since all 16 table entries are used up,
we must replace one of the unused baud rate divisors with a 0 divisor.
I have never seen anyone use 50 baud devices.  The code that recognizes
76800, uses the table entry for 50 baud.

In order to modify the kernel table for the zs divisors, use the
following adb commands:


    # adb -w -k /dev/ksyms /dev/mem
    zs_speeds/16d
    _zs_speeds:
    _zs_speeds:     0       3070    2046    1394    1140    1022    766     510
		    254     126     83      62      30      14      6       2
    zs_speeds+2/w0
    _zs_speeds+2:   0xbfe   =       0x0
    zs_speeds/16d
    _zs_speeds:
    _zs_speeds:     0       0       2046    1394    1140    1022    766     510
		    254     126     83      62      30      14      6       2

This modifies the in-memory copy only.  To modify /vmunix, use ?w0.
To modify for all future kernels, modify /usr/sys/`arch`/OBJ/zs_async.o

8.2 Central Data SCSIterminal Server Ports

We use SCSI-connected ports from Central Data of Champaign, IL, USA
(1-217-359-8010).  We have used the ST-1008 (8 port) and ST-1016 (16
port) models.  They are capable of all the normal baud rates, plus
57,600 baud.  Many V.32bis modems support 57600 baud, which is the
theoretical baud rate maximum when using V.32bis + V.42bis
compression.

To enable support for this device, edit the "Makefile.hw" file, and add
the directive "-DSTS" to the HWSUPPORT definition.  This is not defined
by default, since using this software requires an include file that is
not normally part of SunOS.

The normal terminal driver designates 4 bits for speed, and all 16 possible
speeds are already defined.  So, Central Data has developed an ioctl which
shifts the definition of all the baud rates down by one place in the table,
making room for a new higher baud rate (57,600).  This is extremely kludgy,
but actually works quite well for us.  You can issue this ioctl once,
then use B38400.  This is simpler in that it does not require code changes.
However, you can get into a situation where the baud extension factor
is set incorrectly, and nothing works right.  Instead, we have modified
the code that handles baud rate in all the software to recognize 57,600
and take appropriate action.  This has been done in the dpd program.
Using "-DSTS" in the Makefile will enable this support.  If you want
to enable dialins on this port, you will need to modify the ttymon
or getty program or provide a wrapper program that will set the baud rate
extension factor correctly.  You may also want to update tip or cu,
as necessary.  We are working on this support now.

Some versions of the driver under Solaris 1.X will output an annoying
message on the console anytime the baud extension factor is set.  If
you have this driver, then you can turn that off with the following adb
commands:

    # adb -w -k /vmunix /dev/mem
    physmem fe9
    ctioctl+260/i
    _ctioctl+0x260: call    _printf
    /W1000000
    _ctioctl+0x260: 	0x0	=	0x1000000
    /i
    _ctioctl+0x260: nop
    $q
    #

If the module is compiled into the kernel, you can do the same
adb commands with a ? instead of / and make the changes in the
compiled kernel.  For a dynamically loaded driver, this will not
work since the address of printf does not get set until the driver
is loaded.  Relocating the nop instruction will not produce the
desired effect.

8. Future work

A few areas are slated for future work as time permits.

We will continue to track the Point to Point Protocol as it is updated
and newer versions are made available

With slow links, there are some problems with the combination of
bursty interactive traffic and large batch file transfer traffic.
A future release will implement Type of Service (TOS) priority queuing
to give priority to interactive packets.  This should help interactive
response on heavily loaded links.

We would like to add some administrative tools that can give a better
picture of the traffic patterns over periods of time.  For instance,
it would be useful to have a report showing how many calls were placed
for what protocol, sorted by number of calls, for a given month.

Further updates to this document will be made as we get feedback from
people using the software.

Support for other platforms will be integrated as interested parties provide
the ports.

There are still a few loose ends on dp-3.0, including support for
Solaris 1.X.  That will probably be done before the 3.1 release.

9. Credits

The bulk of the work has been done at Purdue University by Kirk Smith
(ks@acn.purdue.edu) and has been supported by the Purdue Agricultural
Computer Network.  The Purdue ACN is responsible for networking 97
remote computers to the campus internet.  Right now, 11 remote sites are
in operation and more will come on line as Sun equipment is purchased.

Peter Galbavy of Micromuse Ltd. (Peter.Galbavy@micromuse.co.uk) has provided
invaluable help in several areas.  Among these, were the loadable module
support, integration of newer PPP revisions, significant work on this document,
and much testing and several bug fixes.

Ignatios Souvatzis (ignatios@cs.uni-bonn.de) has offered a great deal
of assistance in testing loadable modules and testing beta releases,
providing many fixes.

Jeff Schwab (jrs@ecn.purdue.edu) has provided updates to the PPP code
to bring the software in line with current revisions of the PPP standard.

Mark Seiden (mis@seiden.com) has edited this document and greatly improved
the readability.

Jim Thompson (jim@tadpole.com) has provided many fixes to the kernel modules
and the DP package in general.
