The Link Dead phase is the state where the physical layer is not ready. The link begins and ends with this phase. In order for the link to proceed to the establishment phase, some external event must take place, e.g., carrier detection, or the network interface being marked as ready to use.

Link Establishment uses the Link Control Protocol (LCP) to establish the connection through a series of Configure packets. The actual options which can be negotiated will be discussed later in this article.

During the Authentication phase, the peers authenticate themselves before network layer protocol packets are transmitted. Although Authentication is not required, it is highly recommended, and should take place as soon as possible after the link has been established.

Once the previous phases are completed, each Network Layer Protocol, such as IP, must be configured separately through the Network Control Protocol. When the Network Control Protocol has been opened, PPP will carry all of the corresponding network layer packets.

The Link Termination Phase results when PPP closes the link, which can take place at any time. This typically occurs in response to a request by a human user, but may also be the result of a physical problem, such as loss of carrier, or an authentication problem. The LCP is used to transmit a sequence of terminate packets. When the link is about to close, PPP notifies each of the Network layers so they may take whatever action is required when the link is terminated.

Internet Protocol Control Protocol (IPCP)

The purpose of the Internet Protocol Control Protocol, or IPCP, is to provide a standard method of encapsulating the varied Network Layer Protocol information over Point-to-Point links. IPCP is the Network Control Protocol for establishing and configuring the Internet Protocol over PPP.

IPCP permits configuration of:

The Compression Protocol option in IPCP allows for the negotiation of a specific compression protocol to be used. By default, compression is not enabled. Currently, the most commonly implemented compression protocol is the Van Jacobson Compressed TCP/IP.

The IP Address option allows the two points to negotiate concerning their "local" IP addresses. One point either sends the IP address it wants to use, or requests the other point to send the address. By default, no IP address is assumed, so an address must be provided by the user or negotiated. This option is often problematic and is a common reason why PPP connections fail. I cover this in more detail later in the article.

The IPCP negotiation is illustrated in Figure 2.

Link Control Protocol (LCP)

The Link Control Protocol includes a series of options to allow for extensive configuration of the link. These options are:

Each of these options can have a significant impact on the performance and quality of the link. However, not all implementations of PPP will react to all of these options (for example, FTP Software's PPP does not provide Link Quality Monitoring reports). This section provides an overview of the options, most of which I discuss in greater detail later in the article.

The Maximum Receive Unit can be likened to the Maximum Transmission Unit found in TCP. The MRU option specifies that one end of the link wants to use larger or smaller packets.

The Asynchronous Control Character Map, or ACCM, is used to remap contol character sequences which may have a detrimental effect on the modems, on related hardware, or on the drivers that run the serial port to which the actual device is connected.

On some links it may be desirable to perform Authentication before allowing network layer protocol packets to be exchanged. This option allows for the negotiation of authentication and the specification of which authentication protocol will be used. By default, no authentication is performed. There are currently two protocols in place for performing authentication: the Password Authentication Protocol, or PAP, and the Challenge Handshake Authentication Protocol. PAP will be discussed in this article, the Challenge method will not.

Link Quality Monitoring (LQM) may be desirable on some links to determine when and how often the link is dropping data. This option allows for the negotiation of LQM, and specification of what protocol will be used to perform the monitoring. By default, monitoring is disabled. Link Quality Monitoring is not discussed in detail here, but those who are interested can review it in RFC 1333.

The Magic Number option is used to provide a mechanism to detect looped-back links and other Data Link Layer anomalies.

Protocol Field Compression allows for compression of the Data Link Layer (DLL) protocol field. Compression reduces the amount of data sent and thus increases the efficiency of the link, particularly at slow speeds, where the less data sent, the better. By default, this form of compression is disabled.

Address and Control Field Compression is used to allow for negotiation of the Data Link Layer address and control fields. Since these fields typically have the same data in them all the time, they are easily compressed. Sending this option to the remote link signals that the sender can receive the compressed data. By default, compression is disabled.

Figure 3 illustrates the LCP negotiation.

Password Authentication Protocol (PAP)

The PAP provides a simple way for peers to identify themselves. It is facilitiated through a two-way handshake mechanism and takes place only on the initial link establishment. Once the link establishment phase has been completed, one end will send the other an ID/password pair repeatedly until authentication is acknowledged or the connection is refused. Only one end should be configured to use authentication: if both ends are configured for PAP, then the connection will never be authenticated. It is important to note that PAP is not a strong authentication method. Passwords are sent in the clear, and there is no protection from repeated trial and error attacks.

The Asynchronous Control Character Map

The ACCM is used to identify which control characters are sent in the clear (in this case, in the clear means that the actual control character is sent). The map itself is four octets, or 32 bits, in length. Each bit corresponds to the control character of the same number. If the bit is set to one, then when the control character is sent, it will be remapped.

For example, bit 19 corresponds to ASCII 19, which is Control-S, or DC3, and bit 17 corresponds to ASCII 17, which is Control-Q, or DC1. So, if bit 19 is set to one and bit 17 is set to one, then when either of these characters is transmitted, it will be remapped. In this case, the ACCM is represented as 0x000A000.

I focused on DC1 and DC3 because for some links they are a problem. Many serial drivers respond to these particular control characters, which suspend and restart the data flow. FTP Software's PPP has the default character map set to remap Control-S and Control-Q. However, SCO assumes that the hardware present to run the link will be responsible for performing the character remapping (which in fact it may perform), and so the ACCM on SCO is set to 0x00000000. The problem is that if the hardware doesn't perform the character remapping, then the link will have problems if it responds to the XON/XOFF signals.

What Is SLIP?

Unlke PPP, SLIP is not an Internet standard. Rather, SLIP provides a de facto standard for the transmission of datagrams over serial lines. Although there are implementations of SLIP which support dialup access, it was originally meant to provide a transmission method for machines that directly connected through a leased line or RS232 Interface.

Compared to PPP, SLIP doesn't provide much: it simply defines a series of characters which frame an IP packet over a serial line. While PPP provides for a wide variety of network layer protocols to be encapsulated using differing network control protocols, SLIP only addresses IP datagrams. There is no negotiation of IP addresses, compression, or the like. The SLIP connection is established, and that is all.

The SLIP Protocol

Given its limited functionality, the protocol for SLIP is far simpler than that for PPP. It simply consists of two special characters – ESC and END. The END character is used to mark the beginning and the end of the SLIP packet. The ESC character is used to mark bytes that match the ESC or END characters. Figure 4 shows an example of a SLIP packet.

SLIP makes no provision for the following:

Addressing – both machines must know the IP address of the remote system so that packets can be appropriately routed. Currently, SLIP has no mechanism for allowing IP addresses to be communicated.

Type Identification – because the packets do not include a type field, only one protocol can run over the LSIP link.

Error Detection/Correction – no detection or correction is provided because any IP application should detect the damaged packets. The high cost of retransmitting packets over a link typically at 2400 baud helps to explain the lack of error-handling capabilities.

Configuring PPP on SCO UNIX using SCO TCP/IP 1.2.1

Before SCO released TCP/IP 1.2.1, it was virtually impossible to connect to an SCO system running PPP, unless the caller was also an SCO system. (My company purchases its Internet connections from UUNET Canada, and it was this information which precipitated our move to use Morningstar Technologies' PPP). Fortunately, this problem has been corrected in Release 1.2.1 of SCO TCP/IP.

For the purposes of this discussion, I will assume that you are using SCO UNIX, and release 1.2.1 of SCO TCP/IP. If you are not, then I strongly advise you to consider upgrading to this release.

Three primary configuration files are used in the SCO implementation of PPP:

/etc/ppphosts: This file lists of all of the known hosts which the system calls, and which call the system.

/etc/pppauth: This file provides for the password information needed for PAP negotiation.

/usr/lib/uucp/Systems: This file contains the calling information for the remote script.

Figure 5 shows the /etc/ppphosts file from the machine I am using to demonstrate this technology. The format for ppphosts is a list of the systems to be called, with the options for the connection for each. Table 1 shows the available options and explanations.

You can use the SCO utility netconfig to configure any of the SCO networking interfaces. netconfig allows you to have up to four configured PPP interfaces. When starting netconfig for the first time, you must choose what you wish to do. Listing 1 is a sample run of netconfig showing how to add a PPP interface.

The netconfig command allows for the addition, removal, and modification of network interfaces, including PPP, SLIP, NetBIOS, NetBEUI, LAN Manager, NFS, and a host of ethernet interfaces.

In the example netconfig session in Listing 1, a number of interfaces are configured, including

–TCP/IP

–NFS

–LAN Manager client

–NetBIOS

–Ethernet over 10baseT

–SLIP Interface 0

–PPP Interface 0

Listing 1 also demonstrates how to add a second PPP interface. When you run netconfig for the first time, your only option is to add PPP interface 0. Once you've added PPP interface 0, the next new interface becomes PPP interface 1.

The information required in the configuration is

–The address of the local PPP connection, e.g., 198.73.137.121

–the address of the remote PPP connection, e.g., 198.73.137.120

–The netmask for the connection, e.g., 255.255.255.0

–The name of the remote connection, i.e. gw-ppp6

–Whether or not you want to enable Password Authentication PRotocol

–Whether or not this a network gateway

The box diagram in Figure 6 shows the configuration of the machine I am using to demonstrate this setup. It has a 10baseT network interface, a SLIP interface, and a PPP interface, all of which are active at the same time.

Upon completing netconfig, you must relink the kernel to add the new network interface. If you choose not to relink, the new interface will not be available for use until you do relink the kernel.

Once the kernel is rebuilt, you need only reboot the system to enable the PPP services. netconfig takes care of all of the nitty-gritty modification of the required files, the most important being /etc/tcp.

/etc/tcp, which is executed at system startup, configures all of the network interfaces and starts all of the TCP/IP services. This includes the pppd executable, which is the PPP Daemon. This daemon makes the phone calls for dialup PPP links and initiates all of the protocol work described earlier.

The calling mechanism is implemented through the services SCO provides for use with its UUCP system. The information required to call the remote system is registered in the file /usr/lib/uucp/Systems.

The Systems file defines the names of the PPP and UUCP systems known to this system. Each entry is in the format

System_Name Time_to_Call Type Speed  Phone_Number  Login_script

For example, consider this entry

gateway Any INTACU 1200 9999999 ""d\r\d\r ogin: nppp22 word: testing

The System_Name (gateway) is the name of the remote machine to be contacted.

Time_to_Call is the calling schedule for this machine. This entry allows you to restrict the times when this machine may be called, which can be handy if the link between the machines is an expensive one.

Type correlates the name of the device with the devices defined in the UUCP Devices file. Any name defined in the Devices file is valid. For a TCP connection, the device named here would be TCP, along with the protocol to be used.

The Speed field sets the speed for the connection to this system. This is defined in baud. No keywords are permitted.

Phone is the actual number to dial when the connection is via modem. Direct connections mark this field with a hyphen (-).

Finally comes what may be the most difficult part of the entry: the chat script. The chat script is a combination of expect-send pairs which implement the login sequence used to gain access to the remote computer. Each pair is separated by a space, with optional subexpect-subsend pairs separated by hyphens. (For more information on the format of the Systems file, please see the article "Administering BNU," in Sys Admin, March/April 1993.)

The /etc/ppphosts file stores the configuration information of the PPP link. This information is used to negotiate the various options which you may wish to configure and adjust. For a further explanation of the options available to the PPP user, see Table 1.

With all of these components in place, the configuration of the link is complete.

Configuring SLIP for SCO UNIX with SCO TCP/IP 1.2.1

On SCO systems configuring SLIP is essentially the same process as configuring PPP, except that the connection is usually direct rather than dialup. Adding SLIP services involves running netconfig, as with PPP, and installing the services in the kernel.

Once you've run the setup session, netconfig adds the required lines to the /etc/tcp file. The program which actually runs the SLIP link is slattach, and there is one running for each SLIP link. For example, the gateway system at my company has a PPP connection to UUNET Canada, a SLIP connection to a machine in the Tech Services Group, a 10baseT connection, and a number of modems capable of supporting either SLIP or PPP connections.

The following sample entry from /etc/tcp establishes a SLIP link:

/etc/slattach tty2c 198.73.137.108 198.73.137.107 9600 &

The arguments to slattach are

port local_IP remote_IP baud

So this line would attempt to establish a SLIP link on port /dev/tty2c at 9600 baud using an IP address of 198.73.137.108 for the local end of the link and an IP address of 198.73.137.107 for the remote end of the link.

Listing 2 contains some sample code which could be added to /etc/tcp to test the SLIP link and mark it as down if the remote host is not operational.

A major difference between PPP and SLIP lies in how each reacts to a lost link. When the PPP link goes down, the connection will be re-established as soon as it is needed again. With SLIP, slattach must be restarted on both ends of the link.

Configuring PPP with Morningstar Technologies (MST) PPP

Morningstar's PPP is somewhat easier to configure than SCO's, in that it does not require kernel modifications or a relink. The release runs on multiple UNIX platforms, including, among others, SUN, DEC, SCO, NEXT and SGI.

For the purposes of this discussion, I assume that you are setting up Morningstar PPP to work over a Telebit T3000 modem, which will be used to establish a connection to a remote machine.

The organization of the files for this implementation is much the same as for the SCO version, as illustrated in Listing 3. The Systems file used by Morningstar is equivalent to that used by SCO. Unlike the SCO version, however, this one allows IP addresses to be used in place of hostnames, which eliminates the need for name resolution. For example, the following is the entry which my company uses to contact our Internet provider, UUNET Canada:

142.77.17.1 Any ACU 19200 5551212 ogin: \
my_login word: password_here

In this example, the connection to 142.77.1.1 is made through a device identified as ACU, and at a speed of 19.2Kb baud. The device information is extracted from the Devices file in the /usr/lib/ppp directory.

The Devices file in Listing 4 provides examples of several different devices which could be used to run a PPP link. Finally, the Dialers file contains the information the PPP daemon must use to communicate with the device in order to establish the connection.

The next stage is to establish a connection, and this is achieved by running an instance of the PPP daemon, pppd. On SCO systems, this pppd replaces the one provided by SCO.

The pppd command requires at least one argument, the minimum being the hostname or IP address of the local IP interface, as in

pppd hostname

or

pppd 198.73.137.101

More typically, however, other options are used on the command line, as for example:

pppd local_IP:remote_IP passive up auto debug 3 mru 756

The PPP daemon must have at least the IP address for the local interface. The remote IP address could be negotiated between the two machines. The passive keyword indicates that the LPC and IPCP negotiations are opened with a passive event, and not an active one (for more information, see RFC 1331 and RFC 1332).

The up keyword indicates that the link should be maintained, and that if the link goes down for any reason, it should be restarted without waiting for an outbound packet. This is often used in conjunction with auto, which puts the daemon into autocall mode, detaches the daemon from the controlling terminal, and initiates the call. This keyword cannot be used unless the remote address is known.

debug 3 indicates that debug statements to a level of three should be saved in the default log file, /usr/adm/ppp.log. These debug statements include information regarding calls being made and connections dropped. The higher levels include line quality monitoring and other information and should also be included in the log.

mru 756 indicates that this PPP would like to handle packets of size 756. Remember that this is the requested size: the remote end doen't have to abide by this request.

Listing 5 shows a sample shell script that our SCO system executes at boot time to start the PPP link.

Configuring SLIP with Morningstar Technologies PPP

The only significant difference between running SLIP and running PPP has to do with the keywords used when the PPP daemon is started. Since SLIP has no negotiating capabilities, all relevant options must be passed on the command line.

pppd local_IP:remote_IP slip

Both SLIP and PPP can be easily managed and maintained with the MST PPP daemon.

Additional SCO Issues

At one point I found that though I had everything configured properly, I couldn't successfully negotiate the PPP link once logged in to the gateway. I contacted Morningstar Technologies and this is what they told me:

That probably means you've run out of STREAMS networking slots into which the STREAMS-based IP tunnel driver can attach itself. Edit /etc/conf/pack.d/ip/space.c and increase the values of IPCNT and IPPROVCNT from 8 and 16 to something like 32 and 64, respectively. Then cd /etc/conf/cf.d; ./link_unix and reboot.

I did what they suggested, and it worked first time around. The exact implication of these two kernel parameters will have to be further investigated.

Configuring FTP Software's PC/TCP for DOS for SLIP and PPP

The FTP technology is DOS based, and allows a DOS system to connect to a PPP server and become part of the network. Worth noting is that FTP Software' s current version of their OS/2 product does not support PPP, but only SLIP.

The FTP implementation of TCP/IP on DOS is a TSR-based executable called the kernel. There can only be one active kernel at any given time under DOS, and so, therefore, only one active interface.

There are a number of different kernels, both card-specific (like wd8003, for the Western Digital series) and generic (like ethdrv and tokdrv). Generic kernels typically require an additional driver to enable communication with the card.

PPP uses the ppdrv kernel with the ppp16550 packet driver; SLIP uses slipdrv with the slp16550 packet driver. This is the only distinguishing characteristic between the two protocols.

pctcp.ini contains most of the configuration information for the PC/TCP system,. The other files affected are

To establish a connection using FTP's implementation, you must make changes to the dialup.scr and hangup.scr files for your remote host and revise your pctcp.ini file.

The first entry in pctcp.ini identifies the serial port to be used. The section is call [pctcp serial N], where N is the number of the serial port section. For example,

[pctcp serial 0]
port=2
io-addr=0x02f8
irq=3
baud=2400
hardware-flow-control=on

identifies the port being used as COM2, and provides the port's io-addr and interrupt information. This information is optional, but may be included if the port is at an IRQ and I/O address other than the usual. The baud rate dictates the speed at which to communicate with the remote device. Because this system is configured for RS-232C modem control signals, hardware-flow-control is set to "on." Otherwise, it would be set it to "off."

The second affected section in the pctcp.ini is [pctcp comscrpt HOSTNAME], where HOSTNAME is the name of the remote machine which you want to access.

Listing 6 provides a sample of the comscrpt section of the pctcp.ini file, showing its layout. Comments have been included for clarity.

The dialup and hangup entries in the comscrpt section tell where to find the dialup and hangup scripts. These generally need to be specific for the remote connection you want to establish. dialup.scr contains the phone number, login name, and password that your machine must use in order to establish a connection to the remote network. hangup.scr contains the modem commands to hang up the line and reset the modem. (Listing 7 presents a sample dialup.scr file showing a connection over a Hayes modem.)

The serial entry in the pctcp.ini file specifies which serial port entry to use (entry 0 in the example in Listing 6). If you have multiple serial ports, you can change this value to indicate which section will provide the information on how the connection should be established. For example, if you have a high-speed modem, but one of your host machines can only handle a lower baud rate, you could indicate this in the pctcp.ini file under a different serial section, so that the file won't need to be edited in the future.

The next entries are the IP parameters for Maximum Receive Unit (which is equivalent to Maximum Transmission Unit) and for control field and protocol field compressions. The maximum receive unit essentially sets the maximum size of a packet to be received from the remote host. This means, according to the protocol definition, that you can request to receive only 296-byte packets, but still must transmit in 1500-byte packets.

The control field and protocol field compression options are used to increase the throughput on the link by compressing these fields.

The ACCM (Asynchronous Control Character Mapping) field allows character sequences like Control-S and Control-Q to be remapped so the serial line isn't affected by them.

The most important items are the local and remote IP addresses. The local IP address is for the PPP interface on the PC you are currently configuring. The remote IP address is for the PPP interface on the UNIX or network host. It may also be necessary to change the subnet mask in the [pctcp ifcust 0] section.

The actual connection is made via the FTP command comscrpt, which connects to the packet driver and starts the modem call. Once the two modems are connected, the comscrpt pogram uses the information in the dialup.scr file to login. A sample dialup.scr is presented in Listing 7.

dialup.scr requires the remote host to provide a user account which will allow for a login negotiation. The login shell on the remote host must be either a PPP daemon or something that will start up a PPP process.

The autoexec.bat File

The autoexec.bat file is executed whenever a DOS system is booted. The sample autoexec.bat in Listing 8 configures the PC, but calls one of several different batch files to start the different network interfaces.

The config.sys file contains nothing related to PC/TCP, unless I want to use the netstart.bat file, which creates a local ethernet interface. For that I need the related drives loaded when config.sys is processed.

The netppp.bat file called in Listing 8 is shown in Listing 9. This file loads the ppp16550 driver (the -p2 forces the driver to use the COM2 port). The pppdrv kernel is then loaded, and finally, the comscrpt command is executed with the name of the host (which must have been defined in a [pctcp comscript HOSTNAME] section).

When comscrpt starts up, it dials the configured phone number in dialup.scr, then enters a login name and password. This file assumes that the login on the machine being called will have a PPP program as the login shell.

Logins

Each machine that will be logging on to the system that provides your PPP gateway services must have a unique IP address for the PC and one for the UNIX end of the PPP link. You can do this most easily by creating distinct login accounts for each machine.

For example, on the SCO UNIX machine which provides my company's PPP services, I created a login account for the PC called "ptopgun," and I set up a password for that account. I then defined a Bourne shell as the login shell.

The Login Shell

To get PPP running so that you can talk to the PC, you'll need to write a shell script which configures the environment and then starts the PPP process. Following is a sample password entry for the "ptopgun" machine:

ptopgun:x:50002:102:PPP Login from
Thumper:/usr/lib/ppp/ppp-users/ptopgun:\
/usr/lib/ppp/ppp-users/ptopgun/Login

And this is the Login shell, /usr/lib/ppp/ppp-users/ptopgun/Login, used to start the PPP process:

:
PATH=/bin:/usr/bin:/etc
mesg n
stty -tostop
export PATH
exec /etc/pppd 198.73.137.101: log $HOME/log
nolqm rfc1172-addresses

The Login shell is an executable Bourne shell script that gets executed at login time. The script configures the serial line, and then runs the PPP process which will communicate with the remote system.

Note that the pppd command in the script is for Morningstar Technologies PPP services; it may not reflect the options used for your PPP daemon. The options used here have the following meaning:

log $HOME/log – log file for transactions

nolqm – no Line Quality Monitoring

rfc1172-addresses – use rfc1172-style addressing.

Only one address is specified on the command line – the IP address for the local interface. This indicates that the IP address negotiation should be attempted, so that the remote host can supply its own IP address.

Starting SLIP for this same PC, I would suggest an alternate login name so that it will be clear whether the user wants a SLIP or PPP connection. The Login shell would be configured in the same fashion, but the arguments would be slightly different:

exec /etc/pppd 198.73.137.101:198.73.137.102 log
$HOME/log slip

Since SLIP does no negotiation at all, the IP addresses for both ends of the link must be supplied to the PPP daemon when it is started. In this case, the only other argument is the keyword SLIP, which denotes that the connection desired is a SLIP-based link, not PPP.

Cautions

While you can do many things on your ethernet or twisted-pair LAN over PPP/SLIP, there are some things that just aren't practical.

For example, if you establish a modem link for PPP at a slow speed, – say, for example, 2400 baud – I would strongly discourage the use of NFS over this link. The time it takes to provide for a directory listing would allow you to go out for pizza and come back.

Conclusions

With PPP and SLIP, a whole new world of internetworking opens up. For small companies and organizations who want Internet access but don't need the bandwidth or can't afford the cost of higher speed services, a 19.2Kb PPP/SLIP link works well.

Also, for those people who take their computers with them or who have computing equipment at home which supports these transports, telecommuting becomes much more feasible: PPP and SLIP allow you to work at home and be as productive as if you were at the office.

While writing this article, I moved from a desktop PC which I took home every weekend to a notebook. My modem travels with me wherever I go, so I can always participate with my company, read my e-mail, and not miss a day's worth of traffic on the Internet.

For More Information

The Point-to-Point Protocol is discussed in detail in the Network Working Group Paper RFC 1331, written by William Simpson.

The PPP Internet Protocol Control Protocol (IPCP) is discussed in detail in the Network Working Group Paper RFC 1332, written by Glenn McGregor.

The PPP Link Quality Monitoring mechanism is discussed in detail in the Network Working Group Paper, RFC 1333, written by William Simpson.

The PPP Authentication Protocol (PAP) is discussed in detail in the Network Working Group Paper RFC 1334, written by Brian Lloyd and William Simpson.

A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP is discussed in detail in the Network Working Group Paper RFC 1055, written by John Romkey.

If you can't get them anywhere else, you can retrieve these working group papers through anonymous FTP from ftp.choreo.ca [192.139.234.50] from the directory ~/rfc. If you experience any trouble in retrieving the files, please send e-mail to sysmom@choreo.ca.

Acknowledgments

I thank the following people for their direct or indirect assistance in the preparation of this article: Blair Baxter, Andrew Goodier, and Patricia Carulli, for ensuring that questions got answered and configurations retested; and Cris Schuldiner and Rich Macchi, from FTP Software, for their help in clearing up some details.

Bibliography

Besides the RFC documents identified above, the following texts also provided information used in this article.

SCO Open Desktop 2.0 System Administrator's Guide. SCO: 1992

SCO Open Desktop/Open Server 3.0 System Administrator's Guide. SCO: 1993

PC/TCP Version 2.2 for DOS Users Guide, FTP Software Inc. FTP: 1993

PC/TCP Version 2.2 for DOS Command Reference, FTP Software Inc. FTP: 1993

TCP/IP Network Administration. Hunt, Craig. Sebastopol, CA: O'Reilly & Associates, 1992.

About the Author

Chris Hare is Ottawa Technical Services Manager for Choreo Systems, Inc. He has worked in the UNIX environment since 1986 and in 1988 became one of the first SCO authorized instructors in Canada. He teaches UNIX introductory, system administration, and programming classes. His current focus is on networking, Perl, and X. Chris can be reached at chare@choreo.ca, or chare@unilabs.org, which is his home.