Jim Mohr's SCO Companion

Index

Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/

Talking to Other Machines

Long ago (at least in terms of the history of electronic data processing) having two computers at the same time was something you read about in science fiction novels. As systems became more common, the time did come when a company or university would have two computers. The need then arose that data be exchanged between the two machines. This was the beginning of SNEAKER-Net (Slow, Non-Electrical Activity, Keeping Everyone Running), which was developed in the 1950s. With SNEAKER-Net, the technician would copy data onto a tape or other media and using his sneakers, would run the tape over to the other machine to be loaded. In many organizations, SNEAKER-Net is still employed today as this is often the only type of network they think they can afford.

In 1976, researchers at AT&T Bell Laboratories came to the rescue. This was the development of a serial line protocol to exchange data between UNIX machines, which came to be known as UUCP, for Unix-to-Unix Copy. Over the years there were several changes, upgrades revisions, etc. In 1983, AT&T released a new version that came to be known as Honeydanber UUCP, as it was had been developed by Peter Honeyman, David A. Nowitz and Brian E. Redman. This is the version currently employed on SCO systems.

Although, UUCP was a good thing, it was limited by the speed of the serial line connecting the two computers. Since the system could only be as fast as it's slowest component, there needed to be a way to speed up that slowest component. Well, serial line speeds increased, but that still was not enough. In the 1970s, Xerox came out with Ethernet, which made high speed communication between computers possible. It was now possible for users to access remote computers and expect response times comparable to being logged in locally, rather than experiencing delays as was common with the serial line communication of the day. (We'll get into more details on Ethernet later.)

Today, both are still wide spread. Although prices have dropped to the point that Ethernet networks are common place (I even have one in my house), UUCP is still used regularly when distances prevent other types of connection, or when the connection is going to be quick or short term and the administrator doesn't want the added hassles of first installing the Ethernet cards.

We are going to talk about both in this chapter. First, we'll talk about UUCP as this is a set of programs that everyone has on their SCO system, even if they don't have ODT or OpenServer. Later, we'll talk about networking principles, especially TCP/IP and the treasure chest (or Pandora's box) of tools and programs that go with it.

UUCP

Perhaps the oldest form of UNIX computer networking is UUCP. UUCP stands for UNIX-to-UNIX-copy and stems from the time when even the ability to copy files directly between computers was a big deal. Today, UUCP is still widely used in systems where more complex networking is either not necessary or not possible. UUCP also provides the ability to remotely execute jobs as well as interactively log in to remote sites.

UUCP and most of it's associated programs are batch oriented. This means that transfers and remote execute requests are "spooled" to be carried out later. The user submits a request and waits for the request to be carried out. There is often little control over when the transfer actually takes place. This is essentially the same way the print spooler works. Jobs are done when the system gets around to it. In most cases, communications between remote systems is carried out according to specific schedules, usually when the phone rates are cheaper.

Because of it's complex nature and the large number of support programs, UUCP could also be considered a system service. UUCP is not only the name of the package or service within SCO, but is also the name of one of the programs within the package. The uucp command is perhaps the most commonly used of the commands, with the interactive login program (cu) a close second. The remote execution command, uux, also places in the top three.

Build into UUCP is several levels of security. The first level is normal file permissions that everyone must adhere to, whether local or remote. The next is the system level security that allows or denies access to your system or to remote system. There is also the ability within UUCP to restrict access to specific directories and commands. This means that although the permissions on a file or directory might give you access to it and your have a valid UUCP account on that system, you still cannot access it. With UUCP you can not only limit access to certain directories, but also to certain commands that can be executed. (Remember UUCP also allows remote execution.)

The SCO UUCP package is essentially the same between ODT and OpenServer. The differences really show themselves when you are trying to configure and administer UUCP, so we will wait until we talk about configuration to talk about these differences. The SCO UUCP package provides two programs for copying files between systems: uucp and uuto. The uucp command is the more common of the two and provides more flexibility. On the other hand, uuto is a little easier to use. Personally, I have never used uuto other than to test a user's command to see if they were doing it right.

For the purpose of this discussion, we're going to assume that there is a valid uucp connection between the two machines. In the second half of the book, when we'll talk about configuring and troubleshooting uucp, we talk about problems ands what to do. We'll also assume that we have three machines, all of which use UUCP. The machine local machine is scoburg. It connects via modem to the machine siemau. Siemau is connected via a direct serial line to the machine vesta.

The reason we are including this third machine is that is possible to transfer file to and from machines via UUCP to which there is no connection. So, if you have connection to one machine (in our case scoburg can talk to siemau) and the second machine can talk to he third (siemau and vesta) you can use the second machine as a bridge between the other two.

Before we start, we need a crash course in the basics. There are three primary files, all of which are located in /usr/lib/uucp . First the Systems file contains a list of which sites (machines) are known to you. The device that UUCP uses to connect to the remote machine is defined in the Devices file. What each machine can do in terms of copying or remotely executing commands is defined in the local Permissions file. For example, what siemau is authorized to do on scoburg is defined in scoburg's Permissions file regardless of who called whom.

Let's assume that we were on scoburg and we wanted to transfer a file to siemau. We start up UUCP which looks in the Systems file to see if it could find siemau. When it does, it then checks to see if this is a proper time to call (also defined in Systems). It then looks through the Devices file looking for an appropriate device (serial port). Once it finds the device UUCP can then beginning calling siemau.

In order for scoburg to be able to log into siemau, an account has to be established. For UUCP to login, it goes through the same procedures as "real" users: it needs both a valid logname (an account) and a password. When UUCP on scoburg gives the correct logname and password, UUCP is started up on siemau and the two UUCPs begin to talk to each other. When they start talking, UUCP on scoburg tells UUCP on siemau that it wants to send a file and where it wants to put that file. UUCP on siemau checks its Permissions file to see if scoburg has authorization to send files in the first place and if so, can UUCP on siemau send the file to the location specified. If it can, then the file is copied. (actually the work is done by the program uucico.)

By default, ODT 3.0 and OpenServer provides a UUCP login account: nuucp. The default Permissions file also allows every uucp login to be able to write to the /usr/spool/uucppublic directory. This directory is available on many different versions of UNIX as a common, generally accessible directory for transferring files. This allows you to easily transfer files with new sites, without having to establish special accounts for them. On the other hand. If every site shares the same UUCP account, they all have access to the same files. Therefore, if security is a concern, then you should consider individual accounts.

Copying Files

So let's get to it. Just keep in mind something I have been saying all along. This book is not a tutorial. I want to show you relationships and how things fit together. In order to do that I need to establish some base level understanding, which is what I am going to do with UUCP We're going to quickly go through some of basics UUCP commands to get a feel for how they work. Then we are going to go into details of what happens behind the scenes.

The primary (read: "most used") command in UUCP is uucp. Surprised? This command allows you to copy files from one UNIX machine to another. UUCP has spread itself so widely throughout the computer world that many vendors supply UUCP for non-UNIX machines, such as what is provided in the MKS Toolkit from Mortice-Kern Systems for DOS.

The syntax of the uucp is essentially the same as the "normal" UNIX copy command: command source destination. The only difference is that normally you want to specify a machine name in the source or destination name (or both). However, this is not a requirement. If you want, you could leave the machine name out completely and use UUCP to copy files on your local machine.

Let's say I wanted to copy a letter I have from my home directory on scoburg and put in the uucppublic directory on siemau. The syntax would be:

uucp /usr/jimmo/letter siemau!/usr/spool/uucppublic/letter

The first thing to notice is the machine name (siemau) is followed by an exclamation mark. This is a flag to UUCP to signify that this is a machine name and not part of the file name. (If you are using the C-Shell, you should switch to the ksh.) If you really don't want to (or can't) then you need to be careful because (remember the chapter on shell basics?) the exclamation mark means something to the C-Shell. Therefore you need to 'escape' it. The syntax for the C-Shell would be;

uucp /usr/jimmo/letter siemau\!/usr/spool/uucppublic/letter

As with other sections, I am not going to give you both csh and (k)sh syntax. Instead, I will just say that when you use csh you need to be careful about the exclamation mark.

Just like the normal cp command, the tilde (~) also has special significant for UUCP. By itself, it refers to the /usr/spool/uucppublic directory. Therefore, the above command could be written as:

uucp /usr/jimmo/letter siemau!~/letter

Not only does this save time in typing, you don't have to worry (too much) about misspelling anything. When I don't do use the tilde, I often have only one 'p' in the middle of uucppublic and my UUCP request will fail.

You can also use the tilde with a user name so it expands to mean their home directory. Therefore, I could have written the command above as:

uucp ~jimmo/letter siemau!~/letter

Which saves me a whole four characters. However, some systems I have seen with hundreds of users, the home directories are scattered across several filesystems. Using this mechanism, you can don't have to know what filesystem a user is on in order to get the file to or from their home directory.

Keep in mind that although you can specify a pathname with this short-cut, you do not automatically have access to that directory. Even if it is your own account. The problem is that UUCP does not know that you are you. To UUCP these are two different accounts, even if they have the same UID and GID. Also keep in mind that you as the submitter of this job must have access to the source file. However, it is UUCP that needs to have access to the destination.

Another way of specifying the file is with relative paths, or no paths, provided I am specifying a file in that directory. If I were already in /usr/jimmo, the above command could look like:

uucp letter siemau!~/letter

or:

uucp ./letter siemau!~/letter

This also works for relative paths, such as:

uucp ../jimmo/letter siemau!~/letter

When the job is submitted to UUCP it will create the appropriate full path name for that file. Also, if you specify the home directory for a user on a remote machine, that user need not exist locally for the expansion to take place. The reason is that the path name is not expanded locally. Rather, the system sends the path name you specify to the remote machine. It is there that the expansion takes place. Because there is no rule as to when and where the expansion takes place, it would be best not to use relative paths when specifying files on a remote machine.

Just as you can copy files from one directory to another, although neither is your current directory, you can copy files from one machine to another, although neither is you local machine. For example, assume our local machine is scoburg, which knows about both the source machine, siemau, and the destination machine, vesta. We can copy files from siemau to vesta with the following command:

uucp siemau!/usr/spool/uucppublic/file vesta!/usr/spool/uucppublic/file

We see from this example that the source machine is remote (remember that we are assuming that the local machine is scoburg). We are taking a file from siemau and copying it to vesta. What happens if we left out the reference to a remote machine when we specified the destination for the file? We would be taking a file from the remote machine and copying it to our local machine. That is, we would be copying from siemau to scoburg.

We can take this one step further and specify multiple machines in our destination. For example:

uucp /etc/motd siemau!vesta!~/filename

Since the local machine (scoburg) does not know about vesta, this is actually the way we would have to run the command. If we tried the first example on scoburg, uucp would have complained immediately that it did not know about vesta.

There are a couple of commonly used options to uucp. For example, you can use the '-j' option to print out the job-ID. If you later decide that you really don't want to send the file (or remotely execute the command), you can use this job-ID to cancel the request.

The '-m' option can be used to send mail to the requester that the file has been transferred or the job executed. Or if you want to notify someone on the remote machine, you can use the '-n' option followed by that user's name.

Depending on how your system is configured, the actual transfer of the file might not take place immediately. As I mentioned before, the Systems file contains information on what is an appropriate time to call. Often calls are only permitted during certain hours to either reduce the traffic on the line or to limit calls to time when the phone rates are less expensive. It may also be the case that your system is configured to never call the other system. Transfer is dependent on the other system calling you. Therefore, as a user, if your request does not go through as quickly as you want, talk to your administrator to find out how UUCP has been configured. If your are an administrator and the request doesn't go through as quickly as you expect, then you probably configured something incorrectly.

What happens to requests is that they are "spooled". This is essentially the same as for the print spooler. There is a special holding area for spooled uucp jobs. At what time UUCP decides to send the message is dependent on your system configuration and we'll get to that a little later.

As with spooled print jobs, there will probably be a time when you would like to find out the status of your spooled UUCP requests. To check the status in the print spooler, you use the lpstat command. To check the status in the UUCP spooler, you use the uustat command.

If I would run uustat after submitting a request:

uucp /etc/motd siemau!~/filename

the output of uustat would look like this:

siemauN522d 05/28-14:45 S siemau jimmo 90 /etc/motd

In this example, there is only one output line. Like lpstat when several print jobs are queued, uustat will also show information on multiple UUCP jobs that are queued. The entries in each line are:

job-ID date/time type_of_job remote machine requester size_of_file file_name

If we take a more complicated example, then the output of uustat get more complicated as well. For example, let's say we want to copy a file from siemau to vesta. Assume there is nothing in the queue and we issue the following uucp command:

uucp siemau!/etc/motd vesta!~/filename

When we run uustat, we now get:

Nothing. Hmmm. What happened? Well, it has to do with the default behavior of uustat. Just as the default behavior of lpstat is to only show us our pending jobs, uustat only shows us the pending uucp jobs. As a result we don't see anything. Because we are actually creating a local uux job that sets up a uucp job on vesta.

Instead we need to use the '-a' option to uustat, which says to show us all queues, not just uucp. This time we get:

vestaN6451 05/28-14:56 S vesta uucp uucp -C siemau!/etc/motd !/tmp

The biggest change is that instead of a size and file name at the end of the line, we have what appears to be a uucp command. This is exactly what it is. What we said was that wanted to copy a file from siemau to vesta. What happens is that UUCP actually creates a job for remote execution on vesta which says to go get the file from siemau. This is why we don't get any output from uustat. It is no longer considered a uucp request, but rather a uux request. If we look in /usr/spool/uucp/vesta we will see both a control file (C.) and a data file (D.)

Remote Execution

Just as uucp allows you to copy to and from different sets of machines, uux allows you to execute commands across sets of machines. For example, I want to print a file on a printer attached to vesta, but the file I want to print is on siemau. I could do this will the command:

uux vesta!lp siemau!/etc/motd

This would actually create two UUCP jobs. This first would transfer the file /etc/motd from siemau to vesta. The second then prints out the file on vesta. In principle we can use uux to execute any command on a remote system. There are two limitations. First, uux is an SUID program, so it is run as the user uucp. Therefore, the user uucp needs to have permissions to run the command. Second, the commands that can be remotely executed may be limited by the Permissions file on the remote machine.

Interactive UUCP Connections

There is one interactive program included in the UUCP package: cu (call UNIX). It's purpose is to access the modem and to dial the number specified, either through the Systems file or directly on the command line. Once the remote modem has answered, cu's work is over. Granted cu does serve as a kind of terminal emulator as it displays the output from the remote system on your screen, however it responds to your commands and does nothing on it's own. Because cu is simply echoing the output of the remote system, you don't even have to be calling another UNIX system!

If the system you called was like UNIX, where you eventually got to a command prompt, then the commands you input would actually be executed on the remote system. Build into cu is also the ability to execute commands on your local system, even though you are attached to (logged into) the remote system.

The format of cu is:

cu [options] destination

As I mentioned above this destination can either be a phone number or the name of a system from the Systems file. If you use a telephone number you can use special character to represent secondary dial-tones(=), or pauses (-).

Let's assume the phone number for siemau was 555-6501. To use cu to connect to it I could do in two ways:

cu siemau

or:

cu 5556501

You can also tell cu to access a particular device using the -l option. rather than trying to dial a phone. For example:

cu -l tty2a dir

This would connect me to the modem attached to /dev/tty2a (assuming there is a modem there)

Build into cu are several commands that are accessed by preceding the command with a tilde (~). Normally cu passes everything to the remote machine. However, if the first character on a line is the tilde, the line is interpreted as a command for cu.

A tilde followed by an exclamation mark (~!) tells cu that you want to execute a shell on the local machine. Although you are still connected to the remote machine, everything you now input is executed on the local machine. To return to the cu session, simply type exit. You can include a command name with the ~!. This will execute the command locally and immediately return you to the cu sessions.

Two other important tilde commands are ~%take and ~%put. These allow you to take a file from the remote machine and copy it to a local file, or put a file onto the remote system from the local system. The syntax is:

~%command source destination

So, if I wanted to copy the remote file file_name and copy it to new_file on my local machine, the command would be:

~%take file_name new_file

Keep in mind that this really only works for ASCII (text) files. The reason for this is that cu command was designed for 7-bit communication. Cu treats every 7-bits as a character. However, the bytes the compose a binary file are 8-bits long. You end up having everything garbled. However, there is a nifty trick that you can use with one of the other UUCP commands: uuencode.

The primary function of uuencode is to convert a set of 8-bit characters to 7-bit and then back again. Well, to the uninitiated, the syntax for uuencode is a bit confusing. The first thing to note is that by default, uuencode sends the results of it's work to stdout. You do give it two names as arguments, but one is the destination name and not the place that the output goes. Confused? Well, lets take an example.

Assume I have a program that I want to transfer named newprg. To uuencode it I might be tempted to input:

uuencode newprg newprg.uue

I am using the convention of .uue as an extension to indicate that this is a uuencoded file. Well, if I were use this command, I would get screen after screen of characters scrolling by. As I said the output of uuecode is stdout, not the filename we give as an argument. To understand this, let's look at the first line of the output:

begin 711 newprg.uue

The first part of the line is the word 'begin'. When we finally get around to decoding the file, this is a flag to tell uudecode where to start. This allows us to include uuencode'd messages as part of email.

Next we have 711. This is the permissions the resulting file will have. At the end of the line is newprg.uue. This is what we input, expecting to be the output file name. This is actually the name of the resulting file when we decode the file. In order to get this into a file so we can transfer it, the command would actually be:

uuencode newprg newprg > temp.uue

Now we have a file (temp.uue) that contains the output of the previous command. If we look at the first line, we see that it is the same as the previous one except that the resulting file name is now newprg and not newprg.uue. We now have a 7-bit file that we can transfer using either ~%put or ~%take.

When we are done, we can terminate the cu session by inputting tilde-dot (~.).

The best way to learn about something is to do tech support for it. That's how I learned about UUCP. One of the first calls I had with UUCP was, fortunately for me, a very basic call. The user was simply having trouble communicating with another machine.

We checked all the configuration files on the local machine and everything made sense. That is, all the files had the right values in the right place. One of the first things to try is cu, which provides an interactive login. If cu works, then you know that the physical connection between the two sites and the software configuration is correct. That is, the modems are set up correctly, you are going through the right device and you have the correct system name and phone number.

We tried to call, but we just couldn't communicate. The biggest problem was that the user didn't have access to the other machine. He was relying on the fact that the administrator from the remote side said the everything was configured correctly. However, we were still not communicating.

After about 20 minutes of checking our configuration and trying to call site with which we could communicate, he both agreed that it had to be something on the remote side, despite what the other administrator said. So, the user called him up on another phone and had him watch and listen as we tried to communicate with him.

Well, we heard the phone ring on the remote side. It rang, and rang and rang. Finally, UUCP gave us an error saying it couldn't connect. So we had the other administrator turn the modem on and off to make sure that it had not gotten into some "weird" state. We tried it again. The phone rang and rang and rang.

Fortunately, there was a set of lights on the font of the modem. One of them was the AA light, for Auto-Answer. The other administrator failed to notice, or failed to tell us, that this light was off. This meant that no matter how hard we tried, the modem wouldn't answer. We were trying to communicate with another site that just wasn't listening. After setting the modem to Auto-Answer, we could communicate with no problems.

Oh, the organization with the communications problems where one side just was listening? The United Nations.

The Flow of Things

Most UUCP files can be found in one of two directories. The /usr/lib/uucp directory contains the UUCP configuration files and many of the support programs. The /usr/spool/uucp directory is the working directory for UUCP. There are several sub-directories here with various functions, which we'll get to in a moment.

There are three key programs that manage and well as supervise UUCP communication. The first, uucico, is perhaps the workhorse of the UUCP package. It is the responsibility of uucico to determine what device should be used to make the connection, starts up the modem dialer programs (more of them in a minute), logs into the remote site and performs the actual transfer of the data.

Figure 0-1 The flow of UUCP

Part of the configuration process of UUCP is to establish UUCP accounts. With these accounts, remote sites can access through the uucico program (among others). When uucico calls a remote site, it logs as a predefined user. This user should have been established as a UUCP user on the remote site. If so, that user does not have a log in shell as we are used to it, but rather has uucico. When your uucico logs into the remote site, the remote uucico starts up and the two start to talk to each other.

To be able to communication with each other, the two uucico programs need to determine whether they both speak the same language. The language they speak is called a protocol and the process they go through is called negotiating the protocol. The most common one used in SCO UNIX systems is the 'g' protocol. This comes in two flavors: G and g.

The entire time it is attempting to log in and afterwards as it is processing and carrying out requests, uucico is maintaining its supervisory roll. It is the responsibility of uucico to ensure that files and commands are only accessed if the system allows it.

To execute commands on a remote machine, you use the uux command. It searches for requests for remote execution, but is also concerned with security and can only execute them is the remote site allows it.

If the connection cannot be made (we'll get into that later), the job remains in the spool directory. Like the print spooler the files in the UUCP spool directory are the only record the system has of pending jobs. If they get removed, then the job must be re-submitted. This obviously not a good thing if the files are removed by accident, however it does allow you to remove files that may be causing problems.

If the remote computer or the device selected to make the connection to the remote computer is unavailable, the request remains queued in the spool directory. This is also what happens when you either tell uucp to specifically hold onto the job or the time permitted to call hasn't bee reached.

By default, there are several entries in the UUCP user's crontab that are related to job scheduling. At 9 and 39 minutes after each hour, cron will start the /usr/lib/uucp/uudemon.hour program. Why it is called uudemon.hour when it runs every half hour is beyond me. Maybe uudemon.half-hour was a bit too much to write. Actually, the reason is the number of characters. UNIX file names are restricted to 14 characters on the traditional UNIX filesystems. Therefore, they couldn't have a file called uudemon.half-hour.

The uudemon.hour program is actually a shell script that contains two commands:

/usr/lib/uucp/uusched &

/usr/lib/uucp/uuxqt &

The uusched program (often called a daemon) checks for pending jobs and schedules them for execution by uucico. The uuxqt program is the remote end of uux, in that it is what executes the jobs that have been submitted for remote execution. It is the uusched program that eventually starts up uucico on the local machine.

To get a better understanding of what happens, lets go through an example. Let's assume your local machine is scoburg and you wish to send a file to the remote machine siemau. The command you would enter would be

uucp file_name siemau!/usr/spool/uucppublic

Remember from our discussion on the various shells that the exclamation marks means something to the C-shell. Therefore you have to escape it by placing a backslash in from of it, as in:

uucp file_name siemau\!/usr/spool/uucppublic

Work files are created in the /usr/spool/uucp/siemau directory. Each system will have its own sub-directory under /usr/spool/uucp, but these are not created until the first request is submitted. There is a control file, whose name has the format C.siemau#xxxx, where # is the grade, or processing priority of the request and xxxx is the job number of that particular request. The grade is a single alphabet character (letter) and grades are processed in order from A-Z and then from a-z. The default under SCO OpenServer is 'N'.

After submitting the job above we might have a file in /usr/spool/uucp/siemau that looked like this:

-rw-r--r-- 1 uucp sys 41 May 27 10:49 C.siemauN5214

Since this file is readable by everyone, we could look at it no matter who submitted the job. It contents look like this:

S /use/jimmo/file_name /tmp jimmo -dc D.0 644 jimmo

the format of this file is as follows:

Type of request. Here we have an 'S' for Send a file to the remote machine. This could also be an 'R' to request a file. If we want to remotely execute a job, this would be an 'S' as we are sending a request for remote execution.

Source path name of the file. If we specified a relative path (or no path) uucp will determine the full-path and use the full-path here. If we had specified a path relative to the home directory of a particular user (with the ~username), then the entry would also appear here in that form. In this case we are sending the file /usr/jimmo/file_name. If we are requesting remote executing the source file is the data file (D.).

Destination path. Here too, if we specified a relative path (or no path) uucp will determine the full-path and use the full-path here. If we had specified a path relative to the home directory of a particular user, then the entry would also appear here in that form. Here we are simply sending it to the /tmp directory. UUCP will ensure that it gets the right name, in this case motd. This is the same behavior as the cp command. If we are requesting remote execution, the destination name is the same as the control file, but will have an X instead of a C.

The login name of the sender.

List of command options specified to either uucp or uux. Here we have -dc. These are the defaults. The -d says to create directories necessary to copy the file. The -c says not to copy the local file into the spool directory prior to transferring. Instead the file will be copied directly from the source, in this case /usr/jimmo/file_name. (Copy the file if you don't want to change permissions)

Name of the data file. Here is the default of D.0. This means that UUCP will copy the file directly from the source. If I had chosen to copy the file into the spool directory this would point to that file.

Mode of the source file in octal. This is only used when sending files. Check the chmod(C) man-page for details on the octal format of file permissions.

Who to notify. The default is the sender. However, if you used either the -n or -m options.

In this example, I am copying the file directly from the source, in this case /usr/jimmo/file_name. If I had specified the -C option, uucp would have first copied the file into the spool directory. Check the permission here as well. You see that they are 644. That means that everyone, including UUCP has the right to read the file. If UUCP did not have the right to read the file, it would matter whether I specified a copy or not. UUCP would automatically make a copy of that file in the spool directory for me.

The file created by UUCPis referred to as the data file. Its name begins with a D and has the format:

D.siemauXXXXzzz

where XXXX is the sequence/ID number of that job and is the same as the job number on the control file, and zzz is a number used to identify any additional data files associated with that job. This is used when there are several data (D.) files created for a single control file. The format of the files is a single character to identify the type of data followed by the data itself. The meaning of each line is as follows:

U	User's name and system.
F	File to transmit. This normally only appears when sending mail since the D. file is the file being transferred in other cases.
I	Identifies standard input.
0	Identifies standard output.
N	If present, prevents mailing acknowledgment of completion of remote execution.
Z	If present indicates message should only be send if the job failed.
R	Return address of the requester. This is used by mailers that can forward to more than one hop. This is the user mmdf (assuming you are using MMDF).
#	Comments

After completion of the work files, UUCP can now send the job. If UUCP had been told to simply queue up the job (with the -r) option, the job will sit and wait until contact is initiated by either side. It is also possible that the system administrator had specified particular times to call that site and this is not one of them. So, even if you don't specify the -r option, the job will wait in the queue.

First, uucico checks the file /usr/lib/uucp/Systems. If the system you are trying to reachis not listed, or you are not allowed to call at this time, you get an error message.

An entry in the Systems file would look like this:

siemau Any ACU 300-2400 5551212 -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: uusiemau asswd: NoSecret

The entries are:

system time-to-call device-type modem-speed phone-number chat-script

The time-to-call field tells uucico what times you can call the remote site. Here we have the entry Any which means calls are permitted at any time. We could specify specif times of the day or everm days of the week. We'll get into details on this in Chapter 14.

The third entry in the Systems file is the device type that should be used to call out. Using this device type, it searches through the file /usr/lib/uucpDevices for a matching entry. For example, I have an entry in my Devices file that looks like this:

ACU tty1A - 9600-19200 /usr/lib/uucpatdialHA96

The entries are

device-type port dialer-line baud-rate dialer

Here, uucico is looking for an ACU device type. This is an Automatic Call Unit or modem. Since this is the same device as specified in the System file, this line would match. The entry in the Devices file also tells what physical device to use and what modem dialer to use (A modem dialer is a program that is used to access the modem and dial the appropriate number). Using the telephone number from the Systems file, along with the device and dialer from the Devices file, uucico can now call out.

In order to prevent other UUCP processes from accessing the same device and to prevent them from trying to call the same system, uucico creates two lock files in /usr/spool/uucp. The port is locked with the file LCK..ttyxx, where xx is the non-modem control device. This is the convention used, although it is usually the modem control device that you are calling out on. In our example, we are calling out on device tty1A. therefore the lock file would be LCK..tty1a. Check the serial(HW) man-page or the section on device nodes for mode details on this.

The system lock is an similar form: LCK..siemau. In both cases, the LCK file is ASCII and contains the process ID of the process that created the lock. This is useful when trying to figure out who's hogging the modem by downloading dozens of image files when you are trying to transfer your end of month reports.

Now uucico can beginning calling the remote site. At this point we will assume that the connection can be made and the remote side answers. Uucico will attempt to login using the values defined in the chat script portion of the Systems file. Essentially, the chat script tells the calling system what to expect the remote system to send it and what it should send in return. We'll get into more details about this in the second part of the book.

Assuming that the logname and password were correct, scoburg has now successfully logged into siemau. One of the first things that siemau needs to do is to create it's own lock files. It would not be a good thing if one process starting to dial out on the port you were calling in on. These have the same format on siemau as on scoburg, however the system lock (obviously) has the form LCK..scoburg.

As I mentioned before, the shell that uucp users have is uucico. It starts up on siemau and the two uucico's start to talk to each other. One of the first things they do it to negotiate the protocol. Keep in mind that there is a lot more to the actual login process than that. However, this covers the main steps and provides a good background for understanding the flow of things.

The uucico on siemau needs to ensure that the uucp user calling from scoburg is allowed access to where it wants to go. It does so by checking the file /usr/lib/uucp/Permissions. Once siemau has determined that the UUCP user calling from scoburg has access it begins transmitting the file in small "packets". These packets are of a specific size. Changing them in SCO ODT 3.0 and earlier was not as straightforward as the /usr/lib/uucp/Configuration file in SCO OpenServer. Within each packet is a checksum, If siemau 0 determines that a packet was garbled during transmission, it will ignore (drop) the packet. Since it acknowledges each packet it receives successfully, scoburg will see that this packet was not received and will resend it.

To ensure integrity of the destination file, the uucico on siemau writes the file into a temporary file as it is receiving it. This is in the /usr/spool/uucp/scoburg directory, with the name TM.xxxx. When the transfer is complete, the file is moved to the specified destination, in this case /tmp/file_name. (We hadn't specified the destination file name, so uucico assumes that it the same name)

As this whole thing is going on, both sides are logging the information. On scoburg there will be a file /tmp/siemau. You can watch the progress of the transfer by using:

tail -f /tmp/siemau

The -f option tells tail to keep reading from the file as new lines are appended to the end. If you are siemau, there is a file /tmp/scoburg which you can watch with tail as well. The information in these files is for a particular session. Information is logged on a semi-permanent basis in /usr/spool/uucp/.Log/uucp/<system_name>.

If scoburg has more files to send to siemau, the process continues until there are none left. Scoburg tells siemau that it wants to hang up. If siemau doesn't have any files to send to scoburg, then they shut down communications. If siemau does have files, the roles are reversed and now siemau is the master and scoburg is the slave. The process continues until siemau no longer has files to transfer. Siemau requests to hang up. It's possible that during the time siemau was the master, a new job was submitted on scoburg. It then becomes the master once again. In theory, this go could back and forth indefinitely although I have never seen more than two role reversals.

After the connection is stopped, the uucico on both sides can remove the lock files for both the port and the system.

Look back at the beginning of the chapter when we covered the basics of UUCP command syntax. There was an example, where we copied a file from a remote machine to another remote machine:

uucp /etc/motd siemau!vesta!~/filename

If we change it slightly so that the source is also on a remote machine, we get:

uucp siemau!/etc/motd siemau!vesta!~/filename

UUCP recognizes the fact that both the source and the destination are on a remote machine. It therefore creates a remote execution command and not a simple file transfer. In other words, the local uucp command creates the necessary files so that another uucp command is executed on the remote machine (siemau). The contents of this command is to copy the local file /etc/motd to the destination "vesta!!/filename". In this case it happens that there is another remote machine involved (vesta). As a result, the file gets copied from siemau to vesta. (Assuming all the Permissions, etc are set right on siemau and vesta)

Where Things Live

There are three directories that UUCP uses. The first one, we've talked about in great detail already. This is /usr/spool/uucp. Like the /usr/spool/lp directory is for the print spooler, this directory is the working directory for UUCP. Here you'll find all the work files, locks, log files, etc. There are several sub-directories here as well. These are:

.Admin	Administrative files. Contains information on transfer statistics and accounting information.
.Corrupt	Corrupt work and execute files that could not be processed
.Log	Log files. One sub-directory for each of uucp, uucico, uux, uuxqt.
.Old	Old log files
.Sequence	System sequence numbers
.Status	Status files. One file per system.
.Workspace	UUCP temporary working area
.Xqtdir	Temporary workspace for remote executions

Plus there is one sub-directory for each system.

Most of the UUCPconfiguration programs and files are store in /usr/lib/uucp. Many of them we have already mentioned when going through the example transfer, but I would like to cover them briefly again.

The Systems file contains a list of the remote systems that are know to you. This file determine what kind of device can be used to contact a particular site (Modem, direct-line or TCP), the times that are authorized to call that site, the phone number to call, as well as chat-script, which is sued when logging into the remote system.

The Devices file contains information used to access the physical device, usually a serial (tty) device. This file contains such information as the type of device, speed, and the dialer program to use.

The Permissions file contains a list of permissions/authorizations when transferring files or requesting remote execution. The entries in this file determine what programs you can run on the remote side, which directories you can access and whether or not the remote site can request or send files to your site.

TCP/IP

Before we talk about the details of networking, we should first talk about the process of network communication. Let's take a network program such as telnet. The telnet program allows you to login to a remote system. You end up with a shell just as if you had logged in locally. Although you are input commands on your local keyboard and the output is appearing on your local screen, all other activity is happening on the remote machine.

For simplicities sake, we can say that there is a telnet program running on each computer. When you input something on local keyboard, the local copy of telnet is accepting input. It passes the information through the network to the telnet on the remote machine. The command is executed and the output is handed to the remote telnet. That information is passed back through the network to the local telnet, which then displays the information on your screen.

Although it may appear as there is a constant flow of information between your local machine and the remote one, this is not what is happening. At any given time there may be dozens, if not hundreds of programs using the network. Since only one can use the network at a time there needs to be some mechanism to allow each program to have its turn.

Think back on our discussion on the kernel. When we need something from the hard disk, the system does not read everything at once. If it did, one process could hog the computer if it needed to read in a large file. Instead, disk requests are send in smaller chunks and the program only thinks that it gets everything it wants. Something similar is done with network connections.

Computers are like humans beings in that they need to speak the same language in order to communicate. Regardless of how they are connected, be it serial or Ethernet, the computers must know how to talk to each other. The communication is carried out in a pre-defined manner, called a protocol. Like the protocols diplomats and politicians go through, computer protocols determine how each side behaves and how it should react to behavior by its counterpart. Roughly speaking even the interaction between the computer and the hardware, such as the hard disk, can be considered a protocol.

The most common protocol used by SCO is TCP/IP. However, it is more accurate to call TCP/IP a protocol suite, or protocol family. This is because TCP/IP actually consists of several different protocols. Even the name consists of two different protocols as TCP/IP stands for Transmission Control Protocol/Internet Protocol.

TCP/IP is often referred to as protocol suite as it contains many different protocols and therefore many different ways for computers to talk to each other. However, TCP/IP is not the only protocol suite. There are dozens, if not hundreds of different ones, although only a small portion have gained wide acceptance. SCO only uses a few itself, although the TCP/IP family is what is delivered by default and most commonly used.

Although the name refers to two specific protocols, TCP/IP actually means an entire suite of protocols and programs. The result of many years of planning and discussion, the TCP/IP suite includes a set of standards which specify how computers ought to communicate. By following these standards, computers "speak" the same language and can therefore communicate. In addition to the actual means of communication that the TCP/IP suite defines conventions for connecting different networks and routing traffic through routers, bridges and other types of connections.

The TCP/IP suite is result of a Defense Advanced Research Projects Agency (DARPA) research project on network connectivity. However, its availability has made it the most commonly installed network software. Many versions provide source-code which reside in the public domain allowing users to adapt it to many new systems. Most vendors of network hardware (e.g. bridges, routers) support the TCP/IP suite.

Whereas the data being transferred to and from the hard disk is talked about in terms of blocks, the unit of information transfer across a network connection is referred to as a packet. Depending on the program you are using, this packet can be a different size. In any event they are small enough to send across the network fast enough, so that no one process hog the network. In addition, the packets go across the network so fast that you don't notice that your data is broken in to packets. This is similar to the way the CPU manages processes. Each one gets a very small turn on the processor. Because it switches so fast between processes it only seems like you have the processor to your self.

If we take a step back and look at the process of network communication more abstractly, we see each portion supported by and supporting another. We can say that each portion sits on top of another. Or in other words the protocols are stacked on top of each other. Therefore, TCP/IP is often referred to as a protocol stack.

Each portion of the stack is referred to as a layer. At the bottom of the stack is the layer that is responsible for the physical connected between the two computers. This is the physical layer. Sitting on top of the physical layer is layer that is responsible for the network portion of the stack. That is, it ensures that packets either stay on the network or get to the right network and at the same time ensures that packets get to the right network address. this is the network layer.

On top of the network layer is the layer that ensures that the packets have been transmitted correctly. That is, there are no errors and all packets have been received. This is the transport layer. Finally, at the top of all of this is the layer that the user sees. Since the programs that we use are often called applications, this upper layer is called the application layer.

Figure 0-2 Network Layers

Conceptually, each layers is talking to its counter part on the other system. That is, telnet on the local machine is passing data to telnet on the remote machine. TCP on the remote machine sends an acknowledgment to TCP on the local machine when it receives a packet. IP on the local machine gets information from IP on the remote machine that tells it that this packet is destined for the local machine. Then there are the network interface cards that communicate with each other using their specific language.

This communication between corresponding layers is all conceptual. The actual communication takes place between the different layers on each machine not the corresponding layers on both machines.

When the application layer has data to send. It prepends an application header onto the data it needs to send. This header contains information necessary for the application to get the data to the right part of the application on the receiving side. The application then calls up TCP to send the information along. TCP wraps that data into a TCP packet, which contains a TCP header followed by the application data (including header). TCP then hands the packet (also called a TCP segment) to IP. Like the layers before it, IP wraps the packet up and prepends an IP header, to create an IP datagram. Finally, IP hands it off to the hardware driver. If Ethernet, this includes both an Ethernet header and Ethernet trailer. This creates an Ethernet frame.

As we see, it is the TCP layer that the application talks to. TCP sticks the data from the application into a kind of envelope (the process is called encapsulation) and passes it to the IP layer. Just as the operating system has a mechanism to keep track of which area of memory belongs to what processes, the network has a means of keeping track of what data belongs to what process. This is the job of TCP. It is the also the responsibility of TCP to ensure that the packets are delivered with the correct contents and then to put them in the right order.

Error detection is the job of the TCP "envelope" which contains a checksum of the data contained within the packet. This checksum information sits in the packet header and is checked on all packets. If the checksum doesn't match the contents of the packet or the packet doesn't arrive at all, it is the job of TCP to ensure that packet is resent. On the sending end, TCP waits for an acknowledgment that each packet has been received. If it hasn't received one within a specific period it will resend that packet. Because of this checksum and the resending of packets, TCP is considered a reliable connection.

Figure 0-3 Encapsulation

Another protocol that is often used is the User Datagram Protocol (UDP). Like TCP, UDP sits on top of IP. However, UDP provides a connectionless transport between applications. Services, such as the Network File Service (NFS), that utilize UDP, must provide their own mechanism to ensure delivery and correct sequencing of packets. Since it can be either broadcast or multicast, UDP also offers one-to-many services. Because there is no checking by UDP it is also considered unreliable.

Closest to the hardware level, IP is a protocol that provides the delivery mechanism for the protocols. The IP layer serves the same function as your house addresses, telling the upper layers how to get to where they need to. In fact, the information used by IP to get the pieces of information to their destination are called IP addresses. However, IP does not guarantee that the packets arrive in the right order or that they arrive at all. Just like a letter to your house requires it to be registered in order to ensure that it gets delivered with the content in-tact, IP depends on the upper layers to ensure the integrity and sequencing of the packets. Therefore, IP is considered unreliable.

Since the hardware, that is the network cards do the actual, physical transfer of the packets, it is important that they can be addressed somehow. Each card has its own, unique identifier. This is the Media Access Control, or MAC, address. The MAC address is a 48 bit number that is usually represented by 6 pairs of hexadecimal numbers, separated by (usually) dashes or colons. Each manufacturer of network card is assigned a specific range of addresses which usually are specified by the first three pairs of numbers. Each card has its own, individual address: the MAC address.

When sending a packet, the IP layer has to figure out how to send the packet. If the destination is on a different physical network, then IP needs to send it to the appropriate gateway. However, if the destination machine is on the local network, the IP layers uses the Address Resolution Protocol (ARP) to determine what the MAC address of the Ethernet card is with that IP address.

To figure this out, ARP will broadcast an ARP packet across the entire network asking which MAC address belongs to a particular IP address. Although every machines gets this broadcast, only the one out there that matches will respond. This is then stored by the IP layer in its internal ARP table. You can look at the ARP table at any time by running the command:

arp -a

This would give you a response similar to:

siemau 194.113.47.147 at 0:0:2:c:8c:d2

This has the general format:

<machine name> (IP address) at <MAC address>

Since the ARP table is cached, IP does not have to send out an ARP request every time it needs to make a connection. Instead, it can quickly look in the ARP table to make the IP-MAC translation. Then, the packet is sent to the appropriate machine. This is accomplished by the requesting machine sending out a special message (a broadcast) to all machines in the network asking for a response from whoever "own" a particular IP address. The machine with that address will then respond with the MAC address of that card. This mapping of IP address to MAC address is then stored within the requesting machines ARP cache and is then available for all subsequent transfers.

Status and error information is exchanged between machines through the Internet Control Message Protocol (ICMP). This information can be used by other protocols to recover from transmission problems or by system administrators to detect problems in the network. One of the most commonly used diagnostic tools, "ping", makes use of ICMP.

At the bottom of the pile is the hardware or link layer. As I mentioned before, this can be represented by many different kinds of physical connections: Ethernet, token-ring, fiber-optics, ISDN, RS-232 to name a few.

This four layer model is common when referring to computer networks. This is the model that SCO uses and the one that I will use through the book. There is another model that consists of seven layers. This is referred to as the OSI model, but we won't be using it here.

Network Services

In the discussion above, I used the telnet command as an example of one of the programs that uses TCP/IP. However, there are many others which provide addition services such as transferring files, electronic mail, networking printing, and access to remote filesystems. Products such as SCO OpenServer can expand upon these basics to provide additional services.

One kind of service that SCO OpenServer provides is remote administration. In contrast to previous versions of SCO products which required you to administer all machines local, the SCOAdmin suite of programs allows you to administer machines anywhere in your network. Other products, such as database applications may have one central machine containing all the data and access is gained from the other machines via TCP/IP. Often this access is invisible to the user who just sees the "front end" of the database.

This configuration, where one machine contains the data or resource that an other machine uses is very common in computer networking. The machine with the resource that it is providing to other machines is referred to as the server, because it is serving the resource to the other machine. The machine that is using the resource is called the client. This model, where one machine is the server and the other is the client is referred to as a client-server model. The client-server model is the primary model used in SCO networks.

Another common network model is the peer-to-peer model. In this model, there is no one central machine that has all the resources. Instead, all machines are on equal status. Often times, these two models sort of blend together. In SCO UNIX networks, it is possible to have multiple servers, each providing many of the same resources. In can also happen that multiple machines all have resources that the others need so everyone is acting as both a client and a server, similar to peer-to-peer.

On SCO systems, there are dozens of resources available. Many of which are well-known such as telnet, others, such as ntp are more obscure. Like calling into a large office building with a central switchboard, our server needs to know what numbers are associated with which programs in order to make the proper connection. In the same regard, you need to know what office you want to reach before you call. In some cases you can call and say you want a particular extension. In other cases, you say you want a particular office. In a office building there is a list of available "services", called a phone book. On a SCO UNIX system the phone book is the file /etc/services.

The /etc/services file contains a list of what services a particular machine may have to offer. The concept of a service is slightly different than the concept of a resource. A machine may provide many resources in the form of login shells that it provides to remote users, however all of them are accessing the machine through the one service: telnet.

In addition to what service the machine provides, /etc/services also lists the port. To understand the idea of a port, think about this as being the telephone number. When I call in to a machine (say using telnet), I am connected to the telnet program on the other side through a particular port. This is as if I were calling a large office building with a single switchboard. When I reach that switchboard, I tell the operator which office or person I want to talk to. In the ancient history of telephones, that operator had to make the connection between the incoming line and the office herself.

A port can be thought of as the sockets that the operator plugs the phone lines into. Like in that office building, there may be a set of these sockets, or ports, that are directly connected to a specific person (i.e. service). These are well-known ports. There may be offices with their own operator (maybe just a receptionist) who passes the incoming phone call to the right person or may even pick someone themselves to take the call (such as when you call a government agency with a generic question and there is no one person responsible for that area).

On an SCO UNIX system using TCP/IP, the principle is the same. There are dozens of services that one can connect to, but only one way into the system, that's through your network interface card. In order for you to be able to connect to the right service, there has do be something like an operator to make the connection for you. This is the program /etc/inetd. This is the "Internet Daemon" and often referred to as a "super server" since it is inetd's responsibility to wait for requests to access the other servers on your system and pass you along.

Like in our office building, you may know what number you want, that is, which port. When you make the connection to inetd, your process tells it what port you want to connect to and inetd makes the connection. On the other hand, you may have a program that does not have a well-known port. Therefore a new port needs to get created.

The inetd daemon "listens" for the connections. You can say that it is listening on multiple ports in the sense that it manages all the ports. However, it is inetd that makes the connection between the incoming connection and the local port, and therefore to the local server. This mechanism saves memory since you don't need to start up the servers you aren't going to use. This is similar to having a central switchboard and not requiring every office to have their own.

Normally, inetd is started during system start up from a script in /etc/rc2.d. (normally /etc/rc2.d/S85tcp) When it starts, inetd reads its configuration file (/etc/inetd.conf) to obtain the necessary information to start the various servers. It then builds the logical connection between the server and its respective port. Kind of like laying the cable from the central switchboard to the various offices. Technically it creates a socket, which is bound to the port for that server.

When inetd gets a connection request (the phone rings) for a connection-based port, it "accepts" the incoming call which creates a new socket. That is, there is a logical connection between the incoming request and the server. Inetd can now continue to listen on the original port for addition incoming calls.

If the port is connection-less (UDP), the behavior is dependent on entries in the /etc/inetd.conf file. If inetd is told to wait (there is a wait in the fourth column), then the server that was called must process the incoming message before inetd can go on. If told not to wait (there is a nowait in the fourth column), inetd will continue to process incoming requests on that port. If you look in /etc/inetd.conf you see that almost exclusively TCP ports are no wait and UDP ports are wait.

Network Standards

Before we do that we need to side step a little. We need to first talk about what goes into making a standard. Without standards, it makes communication between computers of different type very difficult. Just like you have bus standards like ISA and PCI so hardware can communicate with the CPU, you need some kind of standard.

In the Internet community, standards are both suggested and established through Request for Comments or RFCs. To some extent this are the law. If one product claims to comply with a particular RFC, you know that any other applications that does so should be able to communicate with it. However, RFCs include other things such as lists of previous RFCs and basic introductions to things like TCP.

Becoming a standard is a three step process. Usually, the first few paragraphs of an RFC will tell you to what stage it applies. Assuming of course, that the RFC is part of a standards proposal. At the first stage, the standard is proposed. Organinzing then decide to implement the proposed standard. It requires three separate implementations before the proposal becomes a standard. (Finally, it becomes a standard. This is an oversimplication of the process, since there were also be a lot of discussion about the proposed standard.)

If you need information about a specific network standard, the first place to look is the most current RFC index, which is also published as an RFC. Not only does this list all the RFCs, but will also tell you if one RFC has been replaced and by which one.

Originally I had planned to include a list of the more commonly used and significant RFCs. I eventually realized that this was an unending task. When I started this book, there were just over 1700 RFCs. The last time I checked before wrapping up this book, there were over 1800. Instead I will simply tell you where to get them.

The first place is from the "central repository." These are obtainable using ftp from ftp.ds.internic.net. There is an rfc directory, which contains the RFCs in ASCII as well as many in postscript format. If you know what RFC you want, this can be obtained by sending an email message to mailserv@ds.internic.net. List each RFC you want in the format:

document-by-name rfcXXXX

where XXXX is the number of the RFC. You can obtain the index by including the entry:

document-by-name rfc-index

In addition, the RFCS are available from archives all over the Internet. However, rather than tying up the Internet bandwidth with a lot of copy of files you may not need. Check out the Web page www.cdrom.com or mail info@cdrom.com. This is for Walnut Creek CD-ROM and the sell a CD packed with thousands of documents related to the Internet, including the RFCs. Another site with pretty much the same kind of offering is InfoMagic. They can be reached at www.infomagic.com or info@infomagic.com.

For SCO UNIX systems running TCP/IP one of the most important standards deals with Ethernet. The encapsulation (packaging) of IP datagrams is defined for Ethernet in RFC 894. Developed in 1982 by Digital Equipment Corporation (DEC), Intel and Xerox Ethernet (spelled with a capital) is a standard, rather than a physical entity. Several years later, the 802 Committee of the Institute of Electrical and Electronic Engineers (IEEE or I-triple E), published standards of its own that differed in many ways from the original Ethernet standard. Collectively, these are referred to as the 802 IEEE standards. The 802.3 standard covers networks similar to Ethernet. The IEEE 802 encapsulation was defined in RFC 1042. Both of these use an access method called Carrier Sense, Multiple Sense with Collision Detection or CSMA/CD.

Both of these framing types (RFC 894 and RFC 1042) using a 48-bit addressing scheme. These are generally referred to as the MAC or hardware address. The six bytes of both the destination and source machine are included in the header of both framing types. however, the remainder of the frame is different. As we talked about earlier, This layer is responsible for sending and receiving the IP datagrams. It is also responsible for sending and receiving other kinds of packets as well. These are packets from the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP). We'll talk about both later on.

IP Addressing

In today's world of inter-connected computers, you may have a connection to hundred of thousands of other machines. Granted there is no single cable connecting all of these computers, however there is a logical connection in that you can use the telnet program from your PC in California and connect to a machine in Germany. The problem is, how do the packets get from one end to another. Added to that, how do you keep your local network in California from getting overloaded with packets that are being sent between machines in Germany and at the same time making sure that those telnet packets do get through? The answer is provided by the Internet Protocol (IP).

Just as a street address is not always sufficient to get your letter delivery, so is the IP not always sufficient to get the packet delivered. If I sent you a letter, it could be sent to a single, central post office, whose job it was to distribute mail throughout the entire US. Because of the incredibly large number of pieces of mail, this is impracticle. Instead, there are thousands of offices, all over the country, whose job it is to route the mail for us.

If we lived in a small town, the local post office could catch a letter destined for a local addresss before it goes further. Mail with addresses outside could be sent to other post offices to be processed.

A similar situation applies to IP addresses. In local, self-contained networks, the IP address alone is sufficient. However, when multiple networks are combined, machines spend more time trying to figure out if the packet belongs to them than actually processing information. The solution is a Network Mask. Just as a zip code tells a postal worker whether to process a particular piece of mail locally or not, the Network Mask (or netmask) tells machines whether or not they can simply ignore a packet or need to process it further. How this works, we'll get to in a moment.

Every machine on the network, needs to have its own, unique IP address. Just like every house has a unique mail address. If that network is connected to the rest of the world, that address must not only be unique within the local network, but unique within the rest of the world, as well. As of this writing, IP addresses are 32-bit values. They are usually represented by four sets of numbers, ranging from 0-255 separated by dots (.). This is referred to as dotted-decimal notation. In dotted-decimal notation, an address might look like this:

147.132.42.18

Since each of these numbers range between 0-255, they can be represented by eight bits and are therefore referred to as an octet. This IP address is often thought of as being composed of a network portion (at the beginning) and a node (or machine) portion at the end. This would be comparable to writing a street address as:

95061.Main_Street.42

Where 95061 is the zip code and Main Street is the street and 42 is the address on that street. The reason we write the street address in this fashion, is that it's common to think of the IP address as moving from the general to the more specific.

Currently, there are three classes of networks, which are broken down by both the range used in the first octet and the number of octets used to identify the network. Class A networks are the largest and use the first octet as the network address. Networks in the class will have the first octet in the range 1-126. Class B networks used the first two octets, with the first being in the range 128-192. The smallest networks, class C use the first three octets in the network address and with the first in the range 192-223. How IP addresses are broken down by the different network classes is shown in Table 0.1.

Table 0.1 IP Address Breakdown by Network

There are a couple of things I would like to point out about this table. First, the network address 127 represents the local computer, regardless of what network it is really on. This is helpful for testing as well as many internal operations. Network addresses 224 and above are reserved for special purposes such as multicast addresses. The terms "possible networks" and "possible hosts per network" are those that are calculated mathematically. In some cases, 0 and 255 are not acceptable values for either the network address or the host address.

Keep in mind that a Class A address does not necessarily mean that having 16 million hosts on a single network is impossible to administrate and would over burden most network technologies. What normally happens is that a single entitity, such as Hewlett-Packard is given a Class A address. They will then break it down futher into smaller sub-nets. We'll get into more details about this shortly.

A network host uses the network ID and host ID to determine which packets it should receive or ignore and to determine the scope of its transmissions (only nodes with the same network ID accept each other's IP-level broadcasts). Because the sender's IP address is included in every outgoing IP packet, it is useful for the receiving computer system to derive the originating network ID and host ID from the IP address field. This is done by using subnet masks, as described in the following section.

Subnet Masks

Subnet masks are 32-bit values that allow the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID. Like an IP address, the value of a subnet mask is frequently represented in dotted decimal notation. Subnet masks are determined by assigning 1's to bits that belong to the network ID and 0's to the bits that belong to the host ID. Once the bits are in place, the 32-bit value is converted to dotted decimal notation, as shown in Table 0.2.

Table 0.2 Default Subnet Masks for Standard IP Address Classes

The result allows TCP/IP to determine the host and network IDs of the local computer. For example, when the IP address is 102.54.94.97 and the subnet mask is 255.255.0.0, the network ID is 102.54 and the host ID is 94.97.

Keep in mind that all of this with the subnet masks is the principle and not necessarily the practice. If you (meaning your company) has been assigned a Class B address, then the the first two octents are assigned to you. You could then breakdown the class B net into Class C nets. If we take a look at Table 0.1, we see that there are 65,534 possible nodes in that network. That is really too many to manage.

However, if we considered each of the third octets to represent a sub-net of our class B network, they would all have 254 possible nodes per sub-net. This is basically what a class C net is anyway. We can then assign each sub-net to a department or building and then assign one person to manage each of the class C sub-nets, which is a little easier to do.

To keep the different class C subnet from interfering with each other, we give each sub-net a Class C subnet-mask, although the first octet is in the range for a Class B network. That way machines on this subnet are only concerned with packets for the subnet. We can also break down the sub-nets physically so that there is a gateway or router between the subnets. That way the physical network is not overburdened with traffic from 65,534 machines.

Let's look at a concrete example, like SCO, which has been assigned the Class B address 132.147.0.0. The different departments within SCO have been assigned a class C address that might look like this: 132.147.144.0. Although the first octet (132) says that this is a class B address, it is really the subnet-mask that makes that determination. In this case, our subnet mask would be: 255.255.255.0. Therefore, any packet that is destined for an address other than one starting 132.147.144.0 is not on this network.

It is the responsibility of IP to ensure that each packet ends up going to the right machine. This is accomplished, in part, by assigned a unique address to each machine. This address is refereed to as the Internet address or IP address. Each network gets a set of these IP addresses that are within a specific range. In general, packets that are destined for an IP address within that range will stay within the local network. Only when a packet is destined for somewhere outside of the local network is it "allowed" to pass.

In other words, IP is responsible for the delivery of the packet. It functions similar to the Post Office. Whereby you have both a sending and receiving address. Often times you have many more letters than a single mail bag can handle. The mail carrier (or someone else at the post office) will break down the number of letters into sets small enough to fit in a bag. This is what IP does.

Since there are many people using the line a once, IP will break down the TCP packets into units of a specific size. Although often refereed to also a packets, the more correct terminology is to refereed to IP packets as datagrams. Just like bags of mail need to go from one post office to the next to reach their final destination, IP datagrams must often go through different machine to reach their final destination.

Saying that IP routing can be accomplished completely in software isn't entirely accurate. Although, no physical router is needed, IP can't send a packet to someplace where there is no physical connection. This is normally accomplished by an additional network card. With two (or more) network cards a single machine can be connected to multiple networks. The IP layer on that one machine can then be used to route IP packets between the two networks.

Once configured (how that's done, we'll talk about in the second part of the book), IP maintains a table of routing information, called (logically) a routing table. Every time the IP layer receives a packet, it checks the destination address

Routing and IP Gateways

I mentioned a moment ago that IP is an unreliable, connectionless protocol. That is it contains no provision to ensure that the packet arrives correctly at the destination, nor is there anything the guarantees that when packets do arrive they arrive in the correct order. Although IP is responsible to ensure that the packets get to the right machine, it has essentially no understanding of the physical connection between the two machines. IP will happily run on machines that are connected with something as simple as a telephone wire, to something as complex as satellites. IP depends on some other means to "physically" carry it across the network.

What this means is that the system administrator (or network administrator) is responsible for laying the "map" that is used to define which network address go with what sets of machine and what IP addresses are assigned to individual machines.

One important job that IP does is routing. That is, getting the packet to the right machine. If the source and destination machines are directly connected, that is on the same network, then routing is easy. Essentially there isn't any. IP sees this fact and simply hands the packets off to the data link layer. Otherwise, IP has to figure out how and where to send it.

Usually the 'how' is over a router. A router is some piece of hardware that acts like an air traffic controller send one packet off one way and other off a different way. Often routers are separate pieces of equipment that can be configured in very detailed ways. The disadvantage to this is that with power comes price. The ability to configure a router in many different ways usually means a high price tag. Fortunately, many operating systems, including SCO UNIX allow IP to serve as router-software. Thereby avoiding the cost of router hardware.

In comparison to the router is the concept of a gateway. Like a router, a gateway has knowledge of other networks and how to reach them. In general, we can think of a router as a special piece of hardware that does the work for us. In fact, there are companies that sell equipment called routers. A gateway is more of a concept, in that is the means by which you go from one network to another. Today, the distinction between a router and a gateway is blurred. Routers can server as gateways, gateways can serve as routers.

The path the packet takes from one machine to the next is called a route. Although each machine can maintain static routes for specific destinations, the default gateway is usually used to find remote destinations. (The default gateway is needed only for computers that are part of an internetwork.) If you have a gateway connect to several other networks, there will (probably) be route definitions for each of those other networks.

Let's look at this process as if we were sending a letter, as we did a little while ago. Each letter we send has an envelope which contains a message. On the envelope we write the source and destination addresses. When we mail the letter it gets to the post office and the person sorting the mail checks the destination zip code. If it's the same as the local zip code, the envelope is sent to one of the carriers for deliver. If the zip code is different, then it is sent to some other location. Perhaps all non-local mail is sent to the same place.

If you live across the country from me, the letter probably doesn't go directly from my local post office to yours. (assuming I don't live in San Fransisco and you don't live in New York) The same applies to IP packets. My letter first goes to my local post office, if it is destined for a local address it is processed there. If not, it is sent along to a larger post office. If I sent a letter from Santa Cruz, destined for Annsville, Pennsylvania, it will probably go first to San Fransisco and then to New York (o