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.
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.
In addition, packets can be sent from the user level PPP program
(called ppp). These packets are sent through the "dp" streams
multiplexing device (Sol 2.X) or the dp module (Sol 1.X),
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 "dp" multiplexing streams driver (Sol 2.X)
or the "dpif" streams module (Sol 1.X) where
they are identified by their PPP protocol and sent to the appropriate
upper level stream. This could be the kernel IP stream (Sol 2.X),
a kernel network device (Sol 1.X) 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.
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 is
basically listening for packets with this special bit set in the protocol
field. If no process 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.
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
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. In Solaris 2.X,
the kernel
driver for that interface consists primarily of the "dp" streams
multiplexing device driver.
In Solaris 1.X, the kernel driver is a combined network device driver
and streams module.
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 telephone
system.
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.
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 in Solaris 2.X,
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.
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.
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
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.
Kirk Smith / ks@acn.purdue.edu
Last updated: 28 July 1995