Essential System Administration, 3rd Edition phần 7 potx

These next entries specify information about the tape drive and media to use:
# number of tapes in use Set to at least # tapes required for one full cycle
tapecycle 25 plus a few spares (default=15).
labelstr "Daily[0-9][0-9]*" Format of the table labels (regular expression).
tapedev "/dev/rmt/0"
tapetype "DLT"
#changerdev "/dev/whatever"
#tpchanger "script-path" Script to change to next tape (supplied).
#runtapes 4 Maximum number of tapes per run.
The first two entries specify the number of tapes in use and the pattern used by their electronic labels. Note that tapes must be prepared with amlabel prior to
use (discussed below).
The next two entries specify the location of the tape drive and its type. The final three entries are used with tape changers and are commented out in this
example. Only one of tapedev and tpchanger must be used.
Tape types are defined elsewhere in the configuration file with stanzas like this:
define tapetype DLT {
comment "DLT with 10 GB tapes"
length 12500 mb Tape capacity (takes compression into account).
speed 1536 kps Drive speed.
lbl-templ "file" PostScript template file for printed labels.
}
The example configuration file includes many defined tape types. The length and speed parameters are used only for estimation purposes (e.g., how many tapes
will be required). When performing the actual data transfer to tape, Amanda will keep writing until it encounters an end-of-tape mark.
The following entry and holdingdisk stanza defines a disk holding area:
# When media is unavailable, save this % of holding space
# for degraded-mode incremental backups.
reserve 50 Default is 100%.
holdingdisk amhold0 { Name is amhold0.
comment "Primary holding disk"
directory "/scratch/amanda"
# amount of space to use (+) or save (-); 0=use all (default)
use -2 Gb Always leave this much space.

}
More than one holding disk may be defined.
The final task to be done in the configuration file is to define various dump types: generalized backup actions having specific characteristics (but independent of
the data to be backed up). Here is an example for the normal backup type (you can choose any names you like):
define dumptype normal {
comment "Ordinary backup"
holdingdisk yes Use a holding disk.
index yes Maintain index info on contents.
program "DUMP" Backup command.
priority medium Specify backup relative priority.
# use 24-hour clock without punctuation
starttime 2000 Don't begin backup before this time (8 P.M. here).
}
This dump type uses a holding disk, creates an index for the backup set contents for interactive restoration and uses the dump program to perform the actual
backup. It runs at medium priority compared to other backups (the possibilities are low (0), medium (1), high (2) and an arbitrary integer, with higher numbers
meaning the backup will be performed sooner). Backups using this method will not begin before 8 pm regardless of when the amdump command is issued.
Amanda provides several pre-defined dump types in the example amanda.conf file which can be used or customized as desired.
Here are some other parameters that are useful in dump type definitions:
program "GNUTAR" Use the GNU tar program for backups.
This is also the value to use for Samba backups.
exclude ".exclude" GNU tar exclusion file (located in top-level
of the filesystem to be backed up).
compress server "fast" Use software compression on server using the
fastest compression method. Other keywords are
"client" and "best".
auth "krb4" Use Kerberos 4 user authentication.
kencrypt yes Encrypt transmitted data.
ignore yes Do not run this backup type.
Amanda's disklist configuration file specifies the actual filesystems to be backed up. Here are some sample entries:
# host partition dumptype spindle

hamlet sd1a normal -1
hamlet sd2a normal -1
dalton /chem srv_comp -1
leda //leda/e samba -1 # Win2K system
astarte /data1 normal 1
astarte /data2 normal 1
astarte /home normal 2 # dump all alone
The columns in this file hold the hostname, disk partition (specified by file in /dev , full special file name, or mount point), the dump type, and a spindle
parameter. The latter serves to control which backups can be done at the same time on a host. A value of -1 says to ignore this parameter. Other values define
backup groups within a host; Amanda will only run backups from the same group in parallel. For example, on host astarte , the /home filesystem must be backed
up separately from the other two (the latter may be backed up simultaneously if Amanda so wishes).
There are a few final steps that are needed to complete the Amanda server setup:
Prepare media with the amlabel command. For example, the following command will prepare a tape labeled "DAILY05" for use with the Amanda
configuration named Daily :
$ amlabel Daily DAILY05
Similarly, the following command will prepare the tape in slot 5 of the associated tape device as "CHEM101" for use with the Chem configuration:
$ amlabel Chem CHEM101 slot 5
Use the amcheck command to check and verify the Amanda configuration.
Create a cron job for the Amanda user to run the amdump command on a regular basis (e.g., nightly). This command takes the desired configuration as
its argument.
Amanda expects the proper tape to be in the tape drive when the backup process begins. You can determine the next tape needed for the Daily configuration by
running the following command:
# amadmin Daily tape
The Amanda system will need some ongoing administration, including tuning and cleanup. The latter is accomplished via the amflush and amcleanup
commands. amflush is used to force the data in the holding disk to backup media, and it is typically required after a media failure occurs during an Amanda run.
In such cases, the backup data is still written to the holding disk. The amcleanup command needs to be run after an Amanda run aborts or after a system crash.
Finally, you can temporarily disable an Amanda configuration by creating a file named hold in the corresponding subdirectory. While this file exists, the Amanda
system will pause. This can be used to keep the configuration information intact in the event of a hardware failure on the backup device or a device being
temporarily needed for another task.
11.6.2.5 Amanda reports and logs

The Amanda system produces a report for each backup run and sends it by electronic mail to the user specified in the amanda.conf configuration file. The reports
are quite detailed and contain the following sections:
The dump date and time and estimated media requirements:
These dumps were to tape DAILY05.
Tonight's dumps should go onto one tape: DAILY05.
A summary of errors and other aberrations encountered during the run:
FAILURE AND STRANGE DUMP SUMMARY:
dalton.ahania.com /chem lev 0 FAILED [request timed out.]
Host dalton was down so the backup failed.
Statistics about the run, including data sizes and write rates (output has been shortened):
STATISTICS:
Total Full Daily

Dump Time (hrs:min) 2:48 2:21 0:27
Output Size (meg) 9344.3 7221.1 2123.2
Original Size (meg) 9344.3 7221.1 2123.2
Avg Compressed Size (%)
Tape Used (%) 93.4 72.2 21.2
Filesystems Dumped 10 2 8
Avg Dump Rate (k/s) 1032.1 1322.7 398.1
Avg Tp Write Rate (k/s) 1234.6 1556.2 1123.8
Additional information about some of the errors/aberrations, when available.
Informative messages from the various subprograms called by amdump :
NOTES:
planner: Adding new disk hamlet.ahania.com:/sda2
taper: tape DAILY05 9568563 kb fm 1 [OK]
A summary table listing the data that was backed up and related information:
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOST DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s

hamlet sd1a 1 28255 28255 2:36 180.3 0:21 1321.1
hamlet sd2a 0 466523 466523 36:51 211.1 5:33 1400.8
dalton /chem 1 FAILED
ada /home 1 39781 39781 5:16 125.7 0:29 1356.7

You should examine the reports regularly, especially the sections related to errors and performance.
Amanda also produces log files for each run, amdump.n , and log.date.n , located in the designated log file directory. These are more verbose versions of the
email report, and they can be helpful in tracking some sorts of problems.
11.6.2.6 Restoring files from an Amanda backup
Amanda provides the interactive amrecover utility for restoring files from Amanda backups. It requires that backup sets be indexed (using the index yes setting)
and that the two indexing daemons mentioned previously be enabled. The utility must be run as root from the appropriate client system.
Here is a sample session:
# amrecover Daily
AMRECOVER Version 2.4.2. Contacting server on depot.ahania.com

Setting restore date to today (2001-08-12)
200 Working date set to 2001-08-14.
200 Config set to Daily.
200 Dump host set to astarte.ahania.com.
$CWD '/home/chavez/data' is on disk '/home' mounted at '/home'.
200 Disk set to /home.
amrecover> cd chavez/data
/home/chavez/data
amrecover> add jetfuel.jpg
Added /chavez/data/jetfuel.jpg
amrecover> extract
Extracting files using tape drive /dev/rmt0 on host depot
The following tapes are needed: DAILY02
Restoring files into directory /home

Continue? [Y/n]: y
Load tape DAILY02 now
Continue? [Y/n]: y
warning: ./chavez: File exists
Warning: ./chavez/data: File exists
Set owner/mode for '.'? [yn]: n
amrecover> quit
In this case, the amrecover command is very similar to the standard restore command in its interactive mode.
The amrestore command can also be used to restore data from an Amanda backup. It is designed to restore entire images from Amanda tapes. See its manual
page or the discussion in Unix Backup and Restore for details on its use.
11.6.3 Commercial Backup Packages
There are several excellent commercial backup facilities available. An up-to-date list of current packages can be obtained from
. We won't consider any particular package here but, rather, briefly summarize the important features of a general-purpose backup package, which can potentially
serve as criteria for comparing and evaluating any products your site is considering.
You should expect the following features from a high-end commercial backup software package suitable for medium-sized and larger networks:
The ability to define backups sets as arbitrary lists of files that can be saved and reloaded into the utility as needed.
A capability for defining and saving the characteristics and data comprising standard backup operations.
A facility for exclusion lists, allowing you to create, save, and load lists of files and directories to exclude from a backup operation (including wildcard
specifications).
An automated backup scheduling facility accessed and controlled from within the backup utility itself.
The ability to specify default settings for backup and restore operations.
The ability to back up all important file types (e.g., device files, sparse files) and attributes (e.g., access control lists).
The ability to back up open files or to skip them entirely without pausing (at your option).
The ability to define and initiate remote backup and restore operations.
Support for multiple backup servers.
Support for high-end backup devices, such as stackers, jukeboxes, libraries and silos.
Support for tape RAID devices, in which multiple physical tapes are combined into a single high-performance logical unit via parallel write operations.
Support for non-tape backup devices, such as removable disks.
The capability to perform multiple operations to distinct tape devices simultaneously.
Support for multiplexed backup operations in which multiple data streams are backed up to a single tape device at the same time.

Support for clients running all of the operating systems in use at your site.
Compatibility with the standard backup utilities, which may be important to some sites (so that saved files can be restored to any system).
Facilities for automatic archiving of inactive files to alternate online storage devices (for example, jukeboxes of optical disks) to conserve disk space and
reduce backup requirements.
Inclusion of some kind of database manager so that you (and the backup software) can perform queries to find the media needed to restore files.
See Chapter 5 of Unix Backup and Recovery for an extended discussion of commercial backup package features.
I l@ ve RuBoard

I l@ve RuBoard

11.7 Backing Up and Restoring the System Filesystems
This final section covers backing up and restoring thefilesystem containing the operating system itself,
including the case of a system disk failure. Recovering from such a disaster has come to be known as "bare
metal recovery" in recent years. Unix Backup and Restore includes detailed chapters describing these
techniques and procedures for several Unix varieties.
Filesystems containing operating system files such as / and /usr pose few problems when all you need to
restore is the occasional accidentally deleted or otherwise lost file. When the file in question is an unmodified
system file, you can usually restore it from the operating system installation media, provided you have it and
that it is readable under normal system conditions. If either of these conditions is not true, you should do a
full backup of all system filesystems from time to time.
Files that you modify in the system partitions should be backed up regularly. In Chapter 14, we looked at a
script that saves all modified configuration and other files to a user filesystem, allowing them to be backed
up regularly and automatically via the system backup procedures. Alternatively, the script could save them
directly to the backup media (even to a diskette if the archive is small enough).
When system filesystems need to be completely restored (usually due to hardware problems), some special
considerations come into play. There are often two distinct approaches that can be taken:
Reinstalling from the original operating system installation tapes or CDs and then restoring files you
have modified. This approach may also involve reconfiguring some subsystems.
Booting from alternate media and then restoring the filesystems from full backups that you have made.
Which alternative is preferable depends a lot on the characteristics of your particular system: how many files

have been customized and how widely they are spread across the various system filesystems, how much
device and other reconfiguration needs to be redone, and similar considerations. If you have to restore
multiple partitions, it is usually faster to reinstall the operating system from scratch unless unsaved data in
another partition on the same disk will be lost using the standard installation procedures.
If you decide to take the second route, booting from alternate media and then restoring from a backup, you
will need to make reliable full backups of the system whenever it changes significantly. Because you are
depending on them for a system restoration in an emergency, these backups should be verified or even
made in duplicate.
In either case, you will sometimes also need to consult records of the disk partitions and associated
filesystem layouts, as well as the logical volume configuration, when a logical volume manager is in use. This
is vital when the system disk has been damaged and must be replaced to restore the system to its previous
configuration. Be sure to keep records of this data (see below).
Here is a general procedure for restoring a key filesystem from a backup (some of the individual steps are
discussed in detail Chapter 10):
Boot off alternate media, either an installation tape or CD, or a special bootable diskette or tape
(discussed in a bit). At this point, you will be running off an in-memory filesystem (RAM disk) or one
based on the boot medium.
Create device files for the disks, disk partitions, and/or tape drive that you will need to access, if
necessary. They may already have been provided for you if you used a system utility to create the
bootable tape or diskette.
Prepare the hard disk as necessary. This may include formatting (rarely) or partitioning it. Be sure to
do anything required to make the disk bootable.
Create a new filesystem on the appropriate partition, if necessary.
Mount the system filesystem (/mnt is the conventional location).
Change the current directory to the mount point. Restore the files from the backup tape. Afterwards,
change back to the root directory and dismount the restored filesystem.
Repeat the process for any additional filesystem and then reboot the system.
There is one additional point to consider when using this approach—or planning to rely on it. The filesystem
provided by emergency boot tapes or diskettes is very limited, and only a small subset of the normal system
commands are available. You will need to verify that the restoration utility you need is available after

booting from alternate media. For example, if the boot diskette provides only cpio, the backup of the root
filesystem had better not be a tar archive or you will be in trouble. You should also ensure that any shared
libraries needed by your desired utility are present. Be sure to verify this before the disaster occurs.
We will now look at this process on each of our Unix operating systems individually.
11.7.1 AIX: mksysb and savevg
AIX provides the mksysb utility for creating bootable backup tapes of the actual live system, which are self-
restoring in the event of a failure. It saves all of the filesystems in the root volume group, generally /, /usr,
/var, /home (unless you've moved it), and /tmp, plus any paging spaces in rootvg. mksysb is invoked as
follows:
# mksysb -i /dev/rmt0
mksysb relies on a data file that records various system configuration information. It is updated by including
mksysb's -i option. Use the -m option instead if you wish to restore the exact disk locations of the
filesystems in the root volume group as well as their contents (-m says to save the logical volume maps as
well as the other configuration information).
To restore the root volume group, boot from the mksysb tape and select the appropriate option from the
resulting menu. The system will then be restored from the mksysb tape.
You can use a similar technique to clone a system from a mksysb tape made on a different system. If all the
devices are identical, the only restriction is that you should not install a kernel from a multiprocessor system
onto a single CPU system or vice versa.
When devices differ between the source and target system, a slightly modified technique is used. First, you
boot off the install media, and then you select the option for restoring from a mksysb tape. In this mode, the
operating system will automatically substitute drivers from the installation media when the ones on the
mksysb tape are not correct for the target system. Note that this method will work only if the target system
has the correct drives for accommodating both the mksysb and installation media simultaneously.
11.7.1.1 Restoring individual files from a mksysb tape
mksysb tapes can also serve as nonemergency backups of the root volume group. It is very easy to restore
individual files from it. These tapes contain four distinct (tape) files, and the disk files from the root volume
group are in the fourth file, which consists of a restore archive.
Thus, you could use the following command to restore the file /usr/bin/csh and the subdirectory /etc/mf from
a mksysb backup tape:

# restore -s 4 -x -q -f /dev/rmt0 ./bin/csh ./etc/mf
The -s option indicates which tape file to use, and the -q option suppresses the initial prompt asking you to
press the Enter key after you have mounted the first volume. Use restore's -T option to list the contents of
the archive.
11.7.1.2 Saving and restoring AIX user volume groups
The savevg command may be used to back up an entire user volume group, just as mksysb does for the
root volume group. For example, the following command saves all of the files in the chemvg volume group to
tape drive 1:
# savevg -i chemvg /dev/rmt1
The -i option creates the configuration file needed to save and restore the volume group; using -m instead
also saves the logical volume maps, allowing their physical locations on disk to be reproduced.
savevg also has a -e option, which says to exclude the files and directories listed in the file
/etc/exclude.vgname from the save set.
[21]
Wildcards are not permitted in exclusion lists.
[21]
The mksysb command also recognizes -e, and its exclusion file is /etc/exclude.rootvg.
All of the logical volumes and filesystems and the files within them in a volume group can be restored from a
savevg tape; the restvg utility performs this operation. For example, these commands restore the chemvg
volume group we just saved:
# restvg -q -f /dev/rmt1
# restvg -q -s -f /dev/rmt1 hdisk4 hdisk5
The first command restores the volume group to its original disks, beginning immediately and without
prompting for the first tape volume. The second command restores the structure and contents of the chemvg
volume group to disks 4 and 5, shrinking all logical volumes to the minimum size necessary to hold the files
within them (-s).
The tape made by savevg is a restore archive, so it is easy to extract individual files from it, as in this
example:
# restore -f /dev/rmt1 -T -q
# restore -f /dev/rmt1 -x -q -d ./chem/src/h95

The first command lists the contents of the archive, and the second command restores the /chem/src/h95
subtree, creating any necessary subdirectories (-d).
11.7.2 FreeBSD
FreeBSD provides a several options for restoring system files, but all of them require that you have a
complete backup of the filesystem from which to restore.
In the event of a system disk or boot failure, you must boot from alternate media (CD-ROM or a boot
floppy). Then select the Fixit option from the main menu that appears. At this point, you can choose to boot
from the second installation CD (which will function as a live filesystem) or a fixit floppy, or you can start a
limited shell. The first two options tend to be the most useful.
The fixit floppy is a limited FreeBSD operating system containing enough tools to restore from a backup. It
includes support for the tar and restore commands and tape devices. You create a fixit floppy by
mounting the first installation CD and using a command like this one:
# dd if=/cdrom/floppies/fixit of=/dev/rfd0c bs=36b
This floppy can be customized after creation for your specific needs.
In order to save the disk partition layouts on a FreeBSD system, use the fdisk -s and disklabel
commands. Along with /etc/fstab, this information will allow you to reconstruct the disk partitions and
filesystem layout. The disklabel command can also be used to write a boot block to a replacement system
disk.
11.7.3 HP-UX: make_recovery
HP-UX provides the make_recovery facility for creating bootable recovery tapes as part of theIgnite-UX
package (the utility is stored in /opt/ignite/bin). A common method of using this utility is the following:
# make_recovery -p -A -d /dev/rmt/1mn
# emacs /var/opt/ignite/recovery/arch.include
# make_recovery -r -A -d /dev/rmt/1mn -C
First, we run the command in preview mode (-p). This command does not write any data to tape, but
instead creates the file /var/opt/ignite/recovery/arch.include which consists of a list of the items to be
included. Here, we are choosing to save the entire root filesystem via -A; the default is to save only the
subset of files that are part of the HP-UX operating system.
Once this command completes, we check the /var/opt/ignite/logs/makrec.log1 log file for any errors or
warnings. If any are present, we must take any corrective action necessary and then rerun the first

command.
Once any warnings are dealt with, the arch.include file can be edited to add or remove items, and then
make_recovery can be run again in resume (-r) mode.
[22]
The -C option tells the command to update the
stored data of the most recent make_recovery procedure.
[22]
In some cases, additional considerations apply when some system files reside outside the root
volume group; see the manual page for details.
This process must be repeated after each significant system change. The check_recovery command can be
used to determine if make_recovery needs to be run.
Although these tapes are not intended to replace normal backups, it is possible to retrieve individual files
from them. To do so, you must manually position the tape to the second file and then extract the desired
items with tar:
# cd /
# mt -t /dev/rmt/1mn fsf 1
# tar xvf /dev/rmt/1m relative-pathname(s)
The file list should be specified as relative pathnames (e.g., etc/hosts, not /etc/hosts).
The most recent versions of the HP Ignite-UX package also provide
make_tape_recovery (creates tape recovery images on the client system itself and
from the Ignite-UX server) and make_net_recovery (write a recovery image to the
disk drive of the Ignite-UX server across the network). See the documentation for
details
11.7.4 Linux
On Linux systems, you can create a boot floppy of the current kernel with this command:
# dd if=/boot/file of=/dev/fd0
Simply copying the compressed kernel to diskette is all that is required, because the Linux kernel is
structured so that it is the image of a bootable floppy disk (and it is loadable by either the DOS boot loader
or lilo).
This procedure will enable you to boot your system should there be some problem booting from the hard

disk. However, if your system disk is damaged and the root filesystem there is inaccessible, you will need a
true recovery system to restore things. In such circumstances, you can boot using a rescue disk, which is
created with the installation CD mounted with a command like this one:
# dd if=/cdrom/disks/rescue of=/dev/fd0 bs=18k
The rescue floppy contains tools needed to restore a saved backup, including tape devices and the tar
command.
To record the disk partitioning information, use the fdisk -l command. Along with /etc/fstab, this
information will allow you to reconstruct the disk partitions and filesystem layout, and you can use lilo to
create a boot block on a replacement system disk. Note that its -r option will prove very useful when the
new root partition is mounted at some other point (e.g., /mnt) within the rescue filesystem.
Recent versions of Red Hat Linux also provide a system rescue option when booting
from the installation CD.
11.7.5 Solaris
Solaris provides little in the way of tools for system backup and recovery. You should make full backups of
the root filesystem. You can then boot off alternate media to create a minimally working system and restore
from your backup.
The prtvtoc command along with /etc/checklist will provide the information required to recreate the disk
partitioning and filesystem layout scheme. You can use the installboot command to write a boot block to
the system disk. Note thatboot images are stored within the installed filesystem at
/usr/platform/model/lib/fs/ufs/bootblk, where model is a string corresponding to your specific Sun hardware
model (e.g., SUNW-Sun-Blade-100).
11.7.6 Tru64: btcreate
Tru64 provides the btcreate command for creating a bootable backup tape for the operating system. The
tape consists of a bootable miniature operating system and a complete backup of the system files.
Running btcreate is very easy in that it will prompt you for all of the information that it requires. The
default (suggested) answers are almost always correct. A restore from a btcreate tape will recreate the
logical volume configuration from the original system in addition to restoring all of the system files.
On Tru64 systems, you can use the disklabel -r command to record disk partitioning information and
recreate them if necessary.
I l@ve RuBoard

I l@ve RuBoard

Chapter 12. Serial Lines and Devices
This chapter discusses how to work with serial lines on Unix systems. Traditionally, this meant configuring
terminals and modems, but now the topic's scope has grown to include related facilities as well, such as fax
services and USB.
This chapter begins by considering traditional serial lines. First, we'll look at the special files used for serial
lines and other terminal sessions. Next, we will discuss how to set the characteristics of individual terminals
and generic terminal types. We then go on to consider terminal line configuration issues, including how to
add and troubleshoot new terminals and modems. We'll conclude with a brief look at the HylaFAX fax service
package and USB devices.
NOTE
Celeste Stokely's website, at is an
invaluable guide to all aspects of using serial ports on Unix systems.
I l@ve RuBoard

I l@ve RuBoard

12.1 About Serial Lines
Serial lines were first used for connecting terminals to computers. As time went on, however, many other
devices have been connected via serial lines as well: modems, printers, digital cameras, and MP3 players, to
name just a few. While serial lines are not fast communications channels, they do provide a straightforward,
standardized way of sending data to or from a computer. In traditional contexts, serial lines use the RS-232
communications standard. We will consider this standard in some detail later in this chapter, after we've
discussed some more practical aspects of administering serial lines and devices.
12.1.1 Device Files for Serial Lines
The special files for serial ports vary between systems, but they traditionally have names of the form
/dev/ttyn, where n is a one- or two-digit number corresponding to the serial line number (System V and BSD
style, respectively); numbering begins at 0 or 00. For example, /dev/tty2 and /dev/tty16 correspond to the

third and seventeenth serial lines on a system, respectively (BSD-style systems always use two digits:
/dev/tty02). Terminals, modems, and other serial devices are accessed via these special files.
On more recent System V-based systems, special files for direct terminal lines are stored in the directory
/dev/term and have names that are their line number: /dev/term/14, for example. There are often links to
the older names.
The file /dev/tty (no suffix) serves a special purpose. It is a synonym for each process's controlling TTY. It
can be used to ensure output goes to the terminal, regardless of any I/O redirection.
The special file /dev/console always refers to the system console device. On many workstation systems,
/dev/console is redefined depending on how the workstation is being used. /dev/console refers to the system
CRT display when the system is being used in a nongraphical mode. When a windowing session is running,
however, /dev/console may become one of its windows (rather than the device as a whole).
Systems may have other terminal special files corresponding to devices that they support. For example,
under AIX, the special file /dev/lft is used for the physical workstation console. It comes into play most often
when the console is used as an ordinary character terminal (i.e., its nongraphical, command-line login
mode). It is also the device to which the X server attaches when the workstation is running in its normal
graphical mode.
There are also other terminal devices in /dev used for indirect login sessions via a network or windowing
system; these are the pseudo-terminal devices. Each pseudo-terminal consists of two parts:
The master or control pseudo-terminal, which usually has a device name of the form /dev/pty[p-s]n or
/dev/ptc/n (BSD and System V, respectively). Many systems support both naming formats.
The slave pseudo-terminal (also called a virtual terminal), which has a device name of the form
/dev/tty[p-s]n or /dev/pts/n. It emulates an ordinary serial line terminal for command output.
n is usually a single hexadecimal digit in both cases. The slave pseudo-terminals provide a TTY-like interface
to user processes. The two parts work in pairs, with the same device number n. Output appears in the virtual
terminal, and this device is also what is listed by commands like ps. On recent System V-based systems,
only a single master pseudo-terminal is used for all of the virtual terminals (true for the System V names
under AIX, HP-UX and Solaris; Tru64 has merged the control functionality into the slave device, thus
eliminating use of a master pseudo-terminal special file).
Table 12-1 lists the special files for serial lines and pseudo-terminals on the various systems we are
considering. The special files for the first serial line and the first pseudo-terminal are listed in each case.

Table 12-1. Serial line special files



Pseudo-terminal
Version
Serial line
Dial-out form
Control
Slave
AIX
[1]
/dev/tty0
/dev/tty0
/dev/ptc
/dev/pts/0
FreeBSD
/dev/ttyd0
/dev/cuaa0
/dev/ptyp0
/dev/ttyp0
HP-UX
[1]
/dev/tty0p0
/dev/cua0p0, /dev/ttyd0p0
[2]
/dev/ptmx
/dev/pts/0
Linux
/dev/ttyS0

/dev/ttyS0
/dev/ptyp0
/dev/ttyp0
Solaris
[1]
/dev/term/a
/dev/cua/0
/dev/ptmx
/dev/pts/0
Tru64
/dev/tty00
/dev/tty00
(not used)
/dev/pts/0
[1]
Also provides the BSD-style pseudo-terminal special filenames.
[2]
This form is used for dial-in modems.
As the table indicates, dial-out modems sometimes use a different special file than terminals do. For
example, under Solaris, the special file /dev/cua/0 refers to the first serial line in dial-out mode. Similarly,
under HP-UX, /dev/cua0p0 and /dev/ttyd0p0 both refer to the same serial line and are used for dial-out and
dial-in modems, respectively.
The two special files differ only in their minor device numbers (their subtype within their device class), which
are offset by 128. You can use the ls -l command to find the major and minor device numbers for a special
file; they appear in the size field:
crw-rw-rw- 1 bin bin 1 0x000201 Feb 1 06:59 cua0p2
crw-rw-rw- 1 bin bin 1 0x000201 Feb 1 06:59 cul0p2
crw w w- 1 bin bin 1 0x000200 Jan 15 15:52 tty0p2
crw w 1 uucp bin 1 0x000202 Feb 1 06:59 ttyd0p2
These four devices all refer to the same physical serial port, accessed in different modes: as a dial-out

modem, as a direct serial connection to another computer, as a terminal line, and as a dial-in modem.
You could use the MAKEDEV or mknod command if you needed to create any of these special files for a serial
line. The first is preferred if it is available because it is much easier to use:
# cd /dev
# ./MAKEDEV tty4
This command will create all the special files associated with the fifth serial line.
On systems without MAKEDEV, you must run the mknod command. For example, the following commands
may be used to create the additional outgoing special files for a bidirectional modem on the fifth terminal
line (which is usually named /dev/tty0p4):
# mknod /dev/cul0p4 c 1 0x401
# mknod /dev/cua0p4 c 1 0x401
These commands both create character special files (the c code letter) for device class 1 (serial lines). You
can then use these device files for configuring the serial line in the various contexts (as we'll see).
Alternatively, you can use SAM to create any required special files, via its Peripheral Devices Terminals
and Modems Actions Add Terminal or Add Modem menu path.
12.1.2 The tty Command
The tty command displays what special file is being used for a login session. For example:
$ hostname
hamlet
$ tty
/dev/tty12
$ rlogin duncan
AIX Version 5
(C) Copyrights by IBM and by others 1982, 2000.
$ tty
/dev/pts/4
This user is directly logged in to the 13th terminal line on hamlet. On duncan, his remote session is using
pseudo-terminal 4.
I l@ve RuBoard

I l@ve RuBoard

12.2 Specifying Terminal Characteristics
Unix programs are generally written to beterminal-independent: they don't know about or rely on the
specific characteristics of any particular kind ofterminal, but rather, they call a standard screen manipulation
library that is responsible for interfacing to actual terminals. Such libraries serve to map general terminal
characteristics and functions (e.g., clearing the screen) to the specific character sequences required to
perform them on any specific terminal.
Terminal definitions are stored in databases on the system, and users indicate what kind of terminal they are
using by setting the TERM environment variable (usually at login time). These databases are handled
differently under BSD and System V and are the subject of the next section.
12.2.1 termcap and terminfo
Programs use the name specified in the TERM environment variable as a key into the system terminal
definitions database. Under the BSD scheme, terminal definitions are stored in the file /etc/termcap ; under
System V, they are stored in the subdirectories of the terminfo top-level subdirectory. Some systems provide
both facilities:
AIX
/usr/lib/terminfo
FreeBSD
/etc/termcap (a link to /usr/share/misc/termcap)
Linux
/etc/termcap and /usr/share/terminfo
HP-UX
/usr/lib/terminfo (a link to /usr/share/lib/terminfo)
Solaris
/etc/termcap and /usr/share/lib/terminfo
Tru64
/usr/share/lib/termcap and /usr/lib/terminfo
This section provides a brief overview of termcap and terminfo entries. See the Nutshell Handbook termcap
& terminfo, by John Strang, Linda Mui, and Tim O'Reilly (O'Reilly & Associates), for detailed information

about the Unix terminal definition databases and modifying or writing entries.
12.2.1.1 termcap entries
The BSD termcap database is a text file consisting of a series of entries that describe how different terminals
function. Here is a sample entry for a VT100 terminal:
d0|vt100|vt100am|dec vt100:\
:co#80:li#24:am:ho=\E[H:\
:ku=\EOA:kd=\EOB:
This sample entry is much shorter than an actual entry, but it will serve to illustrate the features of termcap
entries. The first line is a series of aliases for the terminal type. Any entry without a space can be used as
the value of the TERM environment variable. The remainder of the entry is a colon-separated series of
capability codes and values. There are several kinds of capabilities. They can specify:
Data about the terminal
In the sample entry, the co code tells how many columns the terminal screen has (80), the li code
indicates how many lines it has (24), and the am code says that the terminal can automatically wrap
long output strings onto multiple lines on the terminal screen.
The sequence of characters sent to the terminal to get it to perform some action
In the sample entry, the ho code indicates the character sequence required to move the cursor
"home" (the upper left corner of the screen). In these sequences, the ESCAPE character is abbreviated
\E. Thus, to get a VT100 to move the cursor to its upper left corner, you send it the sequence
"ESCAPE [ H."
[3]
[3]
This doesn't mean that if you type this sequence, the cursor will move. This discussion refers
to sequences sent to the terminal as a device, before any hardware interpretation.
The character sequence emitted when a special key is pressed
In the sample entry, the ku code holds the sequence for the up arrow key; on a VT100, the terminal
emits "ESCAPE O A" when you press this key. Similarly, the kd code specifies the sequence emitted by
the down arrow key.
On FreeBSD systems, you must run the following command after modifying the termcap file:
# cap_mkdb /usr/share/misc/termcap

12.2.1.2 terminfo entries
The System V terminfo database is a series of binary files describing terminal capabilities. Each entry is a
separate file in the subdirectory of the main terminfo location that is named for the first letter of its name:
e.g., the terminfo entry for a VT100 is stored in the file terminfo/v/vt100. terminfo entries are compiled from
source code vaguely similar to termcap. Here is the equivalent terminfo source code for the sample termcap
entry for the VT100:
vt100|vt100am|dec vt100,
am, cols#80, lines#24, home=\E[H,
kcud1=\EOB, kcuu1=\EOA,
The following commands are available for manipulating terminfo entries:
tic
Compile terminfo source.
infocmp
List source for a compiled terminfo entry. The -C option says to list the equivalent termcap entry for a
compiled terminfo entry (i.e., translate from terminfo to termcap).
captoinfo
Translate a termcap entry into terminfo source.
12.2.1.3 Modifying entries
If you need to change a termcap entry, you just have to edit /etc/termcap; to change a terminfo entry, list
its source with infocmp, edit the source, and then recompile it with tic. In either case, it's wise to test the
new entry by installing it under a slightly different name (vt100t for example) rather than merely replacing
the old one. The easiest way to create a new entry is usually to find an existing one for a similar device and
then rename and modify it for the new terminal type.
The terminfo commands listed previously are useful not only for modifying terminfo entries or creating new
ones but also whenever you need to convert an entry from one format to the other. For example, I wanted
to use an old terminal I had on an AIX system, but the system had no terminfo entry for it. However, I was
able to find a termcap entry for it on a BSD system, so all I had to do was extract the entry into a separate
file, ship it to the AIX system, run captoinfo on it, and then compile the result with tic.
Users can specify an alternate termcap or terminfo database with the TERMCAP and TERMINFO environment
variables. If their value is a filename, that file (TERMCAP) or directory (TERMINFO) will be used instead of

the usual location. In the latter case, the named directory must contain subdirectories named for the first
letter of the entries they hold, just as the standard location does. Thus, if TERMINFO is set to
/home/chavez/terminfo and TERM is set to etchasketch, the file /home/chavez/terminfo/e/etchasketch must
be a compiled terminfo entry for that device type.
The TERMCAP environment variable can also be used to pre-retrieve a termcap entry; this feature is
discussed in the next subsection.
12.2.2 The tset Command
Once a user has set the terminal type with theTERM environment variable, the tset command can be used
to initialize the terminal. Without arguments, tset sets basic terminal properties to common default values,
including setting the erase, kill, and interrupt characters, and sending any appropriate initialization
sequences for that terminal type. tset is traditionally included in default user initialization files when the
user's default login location is a terminal.
Although it's most often used without options, tset is actually a very versatile utility. For example, it can
prompt for the terminal type if desired by using its -m option. For example, the following command prompts
the user for the terminal type, supplying vt100 as a default, and then initializes the terminal:
$ tset -m ":?vt100"
TERM = (vt100)
If the user enters a carriage return, tset will use vt100 as the terminal type; otherwise, it will use whatever
type the user enters. In either case, tset will then initialize the terminal accordingly. Instead of vt100, you
can enter any terminal type that your system supports.
You can use tset to prompt for and set the TERM variable by including its hyphen option, which directs
tset to echo the terminal type to standard output:
$ TERM=`tset - -Q -m ":?vt100"` Bourne and Korn shells
$ export TERM
% setenv TERM `tset - -Q -m ":?vt100"` C shell
The -Q option suppresses the normal messages tset prints out.
On BSD-based systems, tset can also be used to set the TERMCAP environment variable. When used this
way, the entire termcap entry corresponding to the type named in the TERM variable becomes the value of
the TERMCAP variable. Setting TERMCAP allows programs to start up more quickly, since they don't need to
search the termcap database file.

tset's -s option generates the shell commands necessary to set the TERM and TERMCAP environment
variables (commands are generated for the shell specified in the SHELL environment variable). There are
many ways of executing them; one common way is to use the eval command:
$ eval `tset -sQ -m ":?vt100"`
The tset command in back quotes is executed first. It prompts for the terminal type, initializes the terminal,
and then emits the commands necessary to set TERM and TERMCAP, which are executed by eval. These are
the commands tset produces for the Bourne shell:
export TERMCAP TERM;
TERM=vt100;
TERMCAP=`d0|vt100:co#80:li#24:am:ho=\E[H: . . .';
Another way to execute the emitted commands is to capture them in a file, which is then source'd (in the C
shell):
[4]
[4]
If you're wondering what the exclamation point after the output redirection sign is for, it overrides
the shell's noclobber variable, which prevents files from being accidentally overwritten. With the
exclamation point, any existing file will be overwritten anyway.
tset -sQ -m ":?vt100" >! ~/.tmpfile
source ~/.tmpfile
rm ~/.tmpfile
These are the commands as they might appear in a user initialization file. They can also be kept in a
separate file, to be source'd whenever it is necessary to change the terminal type. The first command
prompts for the terminal type and initializes the terminal. The remaining commands generate and execute
setenv commands for TERM and TERMCAP, and then finally delete the temporary file.
What's in the temporary file? Assuming that the user selects the terminal type vt100 (i.e., assuming that she
selects the default that tset suggests), ~/.tmpfile will look like this:
set noglob;
setenv TERM vt100;
setenv TERMCAP 'd0|vt100:co#80:li#24:am:ho=\E[H: ';
unset noglob;

The set noglob command turns off shell interpretation for the special characters (asterisks and so on) that
are commonly used in termcap entries. Note that if something goes wrong with this sequence of commands,
unsetnoglob will never be executed, and the user will get a shell in which shell wildcards don't work. This is
rare, but it's certainly confusing.
12.2.3 The stty Command
While tset performs type-specific terminal initialization, the stty command can be used to specify generic
terminal and terminal line characteristics (such as parity). Its general syntax is:
$ stty option [value
]
Not all options require values. stty's options are not preceded by hyphens, although some options have a
hyphen as the first character of their name. Options often come in pairs—like echo and -echo—where the
second form means the negative of the first (in this case "no echo").
stty has a large number of options; the most useful are listed in Table 12-2.
Table 12-2. Commonly used stty options
Option
Meaning
Example
n
Baud rate.
38400
rows n
Lines on the screen.
rows 36
columns
n
Columns on the screen.
columns
80
echo
Echo typed characters on the screen.

-echo
erase c
Delete the previous character.
erase ^H
kill c
Erase entire command line.
kill ^U
intr c
Interrupt the foreground command.
intr ^C
eof c
End-of-file signal.
eof ^D
susp c
Suspend the foreground command.
susp ^Z
lnext c
Interpret the next character literally (used to insert control characters into the
command line).
lnext ^V
werase c
Erase the previous word.
werase ^W
rprnt c
Reprint the pending command line.
rprnt ^R
stop c
Pause terminal input and output.
stop ^S
start c

Restart paused terminal.
start ^Q
flush c
Discard all pending (undisplayed) output.
flush ^O
quit c
Kill foreground command and dump core.
quit ^\
oddp
Enable odd parity.
oddp
evenp
Enable even parity.
evenp
-parity
No parity is generated or detected.
-parity
cstopb
Use two stop bits.
cstopb
-cstopb
Use one stop bit.
-cstopb
clocal
Use hard carrier (-clocal means soft).
-clocal
sane
Reset many options to reasonable settings.
sane
For example, the werase option tells stty which character, when typed, should erase the previous word. By

default, it's Ctrl-W. (Try it; many Unix users aren't even aware that this feature exists.
[5]
) Likewise, the
reprint option tells stty which character, when typed, will make the system reprint the line you're
currently typing. The sane option just might help you to restore normal functioning if you accidentally do
something that confuses your terminal.
[5]
Some C shell versions change its behavior. The line bindkey "^W" backward-delete-word in the
.cshrc file will fix it.
Among the most useful stty options is erase, which defines the control sequence that erases the previous
character (performed by the Delete or Backspace key). If the key is echoed as ^H or ^? instead of removing
the previous character:
$ grpe^H^H
A command like the following will fix it:
$ stty erase ^h
This command sets the erase character to Ctrl-H, the sequence emitted by the Backspace key. You can type
the desired keystroke in as erase's argument or use the symbolic form: the caret character followed by the
appropriate letter for that control sequence. Case does not matter, and this symbolic form may be used for
any stty option requiring a character as its value. The code for the Delete key is ^?.
When a terminal has become hopelessly messed up and won't respond to anything, the following command
sequence may help:
^J^Jstty sane^J
This has the effect of clearing out any junk remaining around in the terminal's buffer and then resetting the
terminal to a set of safe settings.
The stty -a command may be used to display the current terminal settings:
$ stty -a
speed 38400 baud; rows 40; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;

time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal
-crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr
-igncr icrnl ixon -ixoff -iuclc -ixany imaxbel opost -olcuc
-ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase
-tostop -echoprt echoctl echoke
stty and the terminal characteristics databases provide complementary information. termcap and terminfo
provide generic information about all terminals of a given type, while stty -a provides information about
the current setting of options that are, for the most part, supported by many terminals. For example, the
vt100 entries provide fairly complete information about the features specific to VT100 terminals. However,
by themselves, termcap, terminfo, and tset do not support users who like or require particular terminal
options—for example, users who like "#" as an erase character (a feature of very, very old Unix systems) or
whose modem only runs at 9600 baud.
[6]
stty controls the TTY device driver, and thus it allows a user to
specify options like these. It can be particularly useful when a user logs in to another system remotely; in
this situation, the properties of the remote connection often don't correspond exactly to the default settings
and must be explicitly changed.
[6]
This term follows colloquial usage, which falsely equates the term baud with bits/sec. The former is
properly defined as "symbols per second, where a symbol encodes one or more bits. Such a definition
is only correctly applicable to the analogue data stream between two modems. For example, a V.32
modem provides 9600 bps at 2400 baud, using 16 different symbols (points in amplitude/phase
space), each encoding 4 bits." (Thanks to Peter Jeremy for that one.)
I l@ve RuBoard

I l@ve RuBoard

12.3 Adding a New Serial Device
To add a new serialdevice to the system, you must perform the following steps:

Physically connect the terminal or modem to the computer.
Determine the special file in /dev that communicates with the serial line.
In the case of terminals, make sure a termcap or terminfo entry exists for the kind of terminal you are
adding. If none exists, you will have to create one.
Add or modify an entry in the relevant configuration files (which files to use depends on the desired
use: login, dial-up, dial-out, and so on).
If appropriate, force init to reread the terminal configuration information.
Each of these steps will be considered in turn.
12.3.1 Making the Physical Connection
This section discusses issues related to making the physical connection between a terminal or modem and
the computer. It is condensed from the Nutshell Handbook Managing uucp and Usenet, by Grace Todino and
Tim O'Reilly (O'Reilly & Associates), with some additions and slight alterations.
The serial cables used to connect computers or terminals to modems are commonly called RS-232 cables;
technically, they conform—more or less—to the Electronic Industries Association (EIA) RS-232C or the more
recent RS-232D standard. By extension (really by bending, if not breaking, the standard), RS-232 cables
have come to be used to connect computers to all kinds of serial devices—terminals, printers, and ports on
other computers, as well as modems.
Full RS-232 cables consist of up to 25 wires, each with a specific function and each intended to carry a
different signal. Only two of the wires are commonly used for data transmission; the rest are used for
various kinds of control signals. In fact, many of the signals defined by theRS-232 standard are rarely used.
Table 12-3 lists the RS-232 signals typically used for serial devices. Accordingly, current devices virtually
always use only a subset of the 25 pins, and smaller connectors containing only the relevant pins are much
more common than ones with the full set.
Table 12-3. RS-232 signals and their functions
Pin Number
Function
Direction (DTE DCE)
1
Frame Ground (FG)
2

Transmit Data (TD)
3
Receive Data (RD)
4
Request to Send (RTS)
5
Clear to Send (CTS)
6
Data Set Ready (DSR)
7
Signal Ground (GND)
8
Data Carrier Detect (DCD)
20
Data Terminal Ready (DTR)
In general, serial communication works as follows. A piece of equipment (a computer or a modem) sends a
signal across the cable by applying a small positive or negative voltage to a specific pin in the cable's end
connector. The signal is carried across the wires in the cable to the corresponding pin at the other end,
where it is detected by another piece of equipment. The voltage either may be held high (positive) as a go-
ahead signal or may pulse quickly to convey data, with the sequence of negative and positive voltages being
interpreted as binary values.
As Table 12-3 indicates, only two of the 25 pins—pins 2 and 3—are actually used for data transmission.
These two lines are used differently by computers and modems. The RS-232 standard defines two types of
equipment: Data Terminal Equipment (DTE) and Data Communications Equipment (DCE). Most (but not all)
computers are DTE; modems are always DCE. DTE uses pin 2 to transmit data and pin 3 to receive it; DCE
does the reverse.
To connect a terminal or computer to a modem or printer (DTE DCE), you want to make the connection
straight through: all the pins on the first device are connected to the corresponding pin on the second device
(see Figure 12-1). To make a connection between two computers (DTE DTE) or between a terminal and a
computer, you need a cable with lines 2 and 3 crossed. The latter is known as a null-modem cable. Modems

use straight-through cables, not null-modem cables.
Figure 12-1. Pin assignments for serial cables
NOTE
If you do not know whether a device is DTE or DCE, you can always tell by measuring the
voltage on pins 2 and 3. The transmitter should always have a negative voltage, even
when idle. If pin 2 is negative, the device is DTE. If pin 3 is negative, the device is DCE.
12.3.1.1 Hardware handshaking and flow control
Pin 7 is the signal ground. It provides the reference against which other signals are measured. A pin is said
to be asserted when a voltage greater than 5 volts (relative to signal ground) is present on the pin. On
the data lines, a voltage more negative than -5 volts is considered a binary 1, and a voltage more positive
than +5 volts is considered a binary 0.
On the control lines, a positive voltage is considered the "on" state and a negative voltage is considered off.
This is the direct opposite of the case for the data lines.
The remainder of the RS-232 lines shown in Table 11-3 are control lines. Most types of equipment (including
modems) are not happy just to receive a stream of data. They need more control through a process called
handshaking. In handshaking, some preliminary communication between the two pieces of equipment must
take place before data can be sent.
Let's consider what type of handshaking might be necessary between a computer and a modem in order to
dial up another computer system.
First of all, on an outgoing call, the computer needs to know that the modem is available to make the call.
Then the modem needs to tell the computer that it has made a connection.
A computer (DTE) asserts pin 20 (Data Terminal Ready) to show that it is ready. A modem (DCE) asserts pin
6 (Data Set Ready). When the modem makes a connection with another modem on the other end, it asserts
pin 8 (Data Carrier Detect) to let the computer know that a connection has actually been established. Most
Unix systems in the U.S.A. ignore DSR and simply rely on DCD alone for this type of handshaking (although
European systems may use DSR). DTR is asserted when a program such as getty opens the device with an
open system call. The open sleeps on the line until DCD is asserted by the modem or terminal on the other
end of the line. These voltages usually remain high during the entire transmission.
[7]
[7]

Modern Unix computers often use a scheme known as soft carrier, in which DCD is assumed always
to be asserted (and the actual line is not checked). Under this approach, only 3 pins are needed for
communication: transmit (2), receive (3), and signal ground (7). Some cables contain only these three
pins. You can enable soft carrier for a terminal line using the stty command's -clocal option or via
settings in a configuration file.
If the voltage on pin 20 drops, it tells the modem that the computer is unable to continue transmission,
perhaps because it is down. The modem will hang up the phone if a call is in progress. If the voltage on pin 8
drops, it tells the computer that the modem no longer has a connection. In both cases, these pins give a
simple yes/no report on the state of the transmission. This form of handshaking is sometimes referred to as
modem control.
There is a further level of handshaking that is used to control the rate of data transmission. Particularly when
transmitting large amounts of data at high speed, it is possible that one end of a link may try to send data
faster than the other end can receive it. To keep this from happening, there is a flow-control handshake that
allows either end to prevent the other from sending any more data until the slower end catches up.
RTS/CTS is used as a kind of throttle. Whenever a DTE device is able to send data, it asserts pin 4, Request
to Send. If the DCE is ready to accept data, it asserts pin 5, Clear to Send. If the voltage on RTS or CTS
drops at any time, this tells the sending system that the receiver is not ready for more data: "Whoa! Hold on
till I get my buffers cleared." Since this flow control handshake is implemented in the serial port hardware, it
is considerably more efficient and reliable than the Ctrl-S/Ctrl-Q (XON/XOFF) handshake that can be
performed in software.
Table 12-4 provides an example of a conversation between computer and modem that illustrates these
principles in action (the plus and minus signs signify raised and lowered voltage, respectively).
Table 12-4. Computer-modem communications
Device
Signal
Meaning
Computer
DTR +
I want to call another system. Are you ready?
Modem

DSR +
I'm ready. Go ahead and dial.
Modem
DCD +
I've got your party.
Computer
RTS +
Can I send data now?
Modem
CTS +
Sure. Go ahead.
Computer
TD
Data sent out.
Modem
RD
Data received.
Modem
CTS -
Hold on for a moment!
Modem
CTS +
I'm OK again. Go ahead!
The previous four steps may be repeated, with either device in the sending role, and either device using
flow control.
Computer
DTR -
I'm done. Please hang up.
Modem
DCD -

Whatever you say.
The function of pins 6, 8, and 20 is asymmetrical between DTE and DCE (in the same way as pins 2 and 3). A
DTE device (a computer or terminal) asserts DTR (pin 20) and expects to receive DSR (pin 6) and DCD (pin
8). Therefore, a null-modem cable must cross these control lines as well as the data lines, allowing DTR (pin
20) on each DTE interface to drive both DSR (pin 6) and pin 8 (DCD) on the other. That is, whenever either
side asserts DTR, the other side thinks it is getting DSR and DCD.