DP - Operational Overview

The software known as Dialup PPP (or dp-4.X) 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.

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.

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.

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.

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 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.

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