To add a new serialdevice to the system, you must perform the following steps:
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.
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 (DTEDCE), 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 (DTEDTE) 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
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.
184.108.40.206 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.
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).
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.
For similar reasons, pins 4 and 5 are also crossed in null modem cables. Figure 12-1, earlier in the chapter, illustrates the pin assignments for a straight through and a null modem cable.
Now that we've considered how they work, it's time to consider actual serial cables. There are several varieties you may encounter, illustrated in Figure 12-2. The cables pictured are the following, from left to right:
Figure 12-2. Serial cables
The latter two connector types are less frequently used these days.
Figure 12-3 displays the pin numbering schemes for the four traditional serial connectors (looking at the front of the connector).
Figure 12-3. Serial cable pin assignments
Table 12-5 lists the pin equivalencies for three cable types.
Finally, the RS-232C standard limits the maximum length for RS-232 cables to 50 feet. In practice, however, they can be used over much larger distances (many hundreds of feet), especially at lower baud rates.
12.3.2 Terminal Line Configuration
Once you've physically connected the device to the computer, you need to assemble the information necessary to configure the line:
Once you have this information, you are ready to modify the appropriate configuration files. The configuration files relevant to terminal lines are very different between the BSD (used by FreeBSD) and System V (almost everybody else) paradigms, and Solaris uses a proprietary facility for handling serial lines. The various versions are treated separately.
220.127.116.11 FreeBSD configuration files
In addition to the termcap file, FreeBSD uses the following configuration files for terminal lines:
/etc/ttys must contain an entry for each terminal-related device to be used, including serial lines used for other purposes (e.g., printers) and pseudo-terminals. Each entry in the /etc/ttys file has four fields:
port command type [flags]
Fields are separated by one or more spaces or tab characters. Comments begin with a number sign and may be placed at the end of an entry or on separate lines. The fields have the following meanings:
off status is used for lines that are down, not in use, or for which no getty command should be run (e.g., a line connected to a dial-out modem). Multiple keywords should not be enclosed in quotation marks, even though they are separated by spaces. For pseudo-terminals, the status field should be blank (not on).
Here are some sample entries:
# dev command type flags ttyd0 "/usr/libexec/getty std.9600" vt100 on secure ttyd1 "/usr/libexec/getty std.38400" dialup off # 555-1111 ttyv0 "/usr/libexec/getty Pc" cons25 on secure ttyp0 none network off
The first entry describes the terminal on the first terminal line. This terminal has type vt100, corresponding to a VT100 terminal. Whenever the terminal line is idle (i.e., whenever a user logs out or when the system enters multiuser mode), init runs the specified getty command, using the std.9600entry in /etc/gettytab to provide information about the terminal line (discussed below). This terminal is enabled, and it is secure, meaning that users may use it to log in as root.
The second entry describes a dialup modem on the second serial line (the baud speed serves only a descriptive function since the line is off). The third line defines a virtual terminal session for a directly connected terminal (or the console), and the final line illustrates the entry form for virtual terminal devices for network use.
18.104.22.168.1 Secure terminal lines
If you wish to allow people to log in as root on a specific terminal, place the keyword secure in the status field for its terminal line. Conversely, you can prevent users from logging in as root by omitting or deleting the keyword secure from this field. For security reasons, secure status should only be granted to the system console and possibly to one or more directly connected terminals. Denying it to pseudo-terminals means that anyone wanting to become root via a network session will need to log in initially as a normal user and then become root. Thus, such users will need to know both a user account password and the root password.
22.214.171.124.2 The /etc/gettyab file
The command field in /etc/ttys usually contains a getty command, which has the following syntax:
"getty gettytab-entry "
gettytab-entry identifies a particular entry in the file /etc/gettytab, specifying the characteristics of this terminal line. This file is similar in form to /etc/termcap. The first line of each entry identifies one or more synonymous names that identify the entry; any name not containing spaces can be used as a valid argument to getty. Subsequent lines describe various line characteristics. Here are some sample lines:
# /etc/gettytab default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:\ :sp#1200:if=/etc/issue: cons8:\ :p8:sp#9600: 2|std.9600|9600-baud:\ :sp#9600: g|std.19200|19200-baud:\ :sp#19200: std.38400|38400-baud:\ :sp#38400:
The names std.n are traditionally used for standard terminal lines, running at n baud. Thus, std.9600 in the previous example refers to terminal lines at 9600 baud. Autobaud modems are set to the type corresponding to their maximum speed. These entries frequently set only the sp (line speed) characteristic.
The default entry sets defaults for all entries; characteristics set in individual entries override them.
126.96.36.199 System V configuration files
System V also uses the getty program to handle terminal lines, but it is started in a different way. In addition to the terminfo and/or termcap databases, the System V-style terminal configuration files are the following:
The lines in /etc/inittab to start getty processes look like this:
Starting at the left, the fields are the inittab identifier, the run levels to which the entry applies, the action to take, and the process to initiate: in this case, getty. The action field for terminal line entries holds either off (for lines not in use) or respawn, which says to start another getty process whenever one exits.
The getty command's syntax varies among these four Unix versions. The preceding examples included the entries for the console device and a modem on the first serial line. In general, the System V-style getty command takes two arguments: the TTY name, corresponding to the name part of the special filename (i.e., without /dev/), and a label to look up in the /etc/gettydefs file, which holds generic line definitions. The label is often the same as the line speed.
Here are a few version-specific comments:
When adding a new device, you'll need to add a new line to /etc/inittab (or modify an existing one). There must be a separate entry in the inittab file for every terminal line on which someone can log in.
188.8.131.52.1 The /etc/gettydefs file
The /etc/gettydefs file is used on HP-UX and Tru64 systems. Here are some sample entries from an HP-UX system:
console # B9600 SANE CLOCAL CS8 ISTRIP IXANY TAB3 HUPCL # B9600 SANE CLOCAL CS8 ISTRIP IXANY TAB3 HUPCL #Console Login: #console 19200 fixed baud entry 19200 # B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S login: #19200 Modem cycle with hardware flow control 28800 # B28800 CS8 CRTSCTS # B28800 SANE -ISTRIP HUPCL CRTSCTS #@S login: #14400 14400 # B14400 CS8 CRTSCTS # B14400 SANE -ISTRIP HUPCL CRTSCTS #@S login: #9600 9600 # B9600 CS8 CRTSCTS # B9600 SANE -ISTRIP HUPCL CRTSCTS #@S login: #28800
Each entry in /etc/gettydefs describes one operating mode. Distinct entries are separated by blank lines. The fields in each entry are as follows:
label # initial flags # final flags # login prompt #next label
The label is used to refer to the entry on the getty command. The initial and final flags are set on the device during the periods before and after login is executed, respectively. Commonly used flags are:
The fourth field in the gettydefs file holds the login prompt used on that line.
The nextlabel field indicates which label should be used next if a break character is received on the line. It is designed to enable cycling through various baud rates on dialup lines. If the next label is the same as the label, no such cycling will occur; this is how hard-wired lines are set up. In our example file, the 19200 entry is hardwired at that speed, and the remaining three entries form a small cycle.
184.108.40.206.2 Setting terminal line types under HP-UX
On HP-UX systems, the default terminal type for each terminal line may be specified in the /etc/ttytype file. It has entries of the form:
terminal-type is the name of a terminfo entry, and line-name is again the name part of the special filename. For example, the following entry sets the default terminal type to vt100 for the fourth terminal line:
vt100 tty0p3 HP-UX vt100 tty03 Tru64
220.127.116.11.3 The Linux mgetty configuration files
mgetty uses several configuration files stored in /etc/mgetty+sendfax:
18.104.22.168.4 Configuring terminal lines under AIX
As we've noted, AIX uses inittab but not gettydefs. Terminal line characteristics are stored in the ODM and may be set or changed with the chdev command. For example, the following command enables logins on /dev/tty0, setting the line speed to 19200 baud; setting the stty modes before a login to hupcl, cread, and tab3 (hang up on close, enable received, and expand tabs to spaces); and setting the stty modes after login is executed to cread, echoe, and cs8 (enable receiver, echo erase characters as backspace-space-backspace, and use 8-bit characters):
$ chdev -1 tty0 -a login=enable -a speed=19200 -a term=vt100 \ -a runmodes='hupcl,cread,table3' \ -a logmodes='cread,echoe,cs8'
Any stty options may be used for the initial and final flags, set with the runmodes and logmodes attributes (respectively).
The login terminal line attribute indicates how the line will be used. When it is given a value of share, connections may take place in both directions (as for a bidirectional model):
# chdev -l tty0 -a login=share ...
A value of disable configures a line for dial-out only, and enable is the correct value for a dial-in-only line.
12.3.3 Starting the Terminal Line
The final step in installing a new serial device is (re)starting its line. To start up a terminal line, you must force init to reread the terminal line initialization information. When it does, init becomes aware that the device has been added and takes the appropriate action (usually starting a getty process for it).
Under FreeBSD, the following command sends a hang-up (HUP) signal to init (process 1):
# kill -HUP 1
init catches this signal and interprets it as a command to reread initialization information without interrupting the system's activity; kill is being used in its generic, signal-sending capacity rather than to terminate a process. Therefore, by modifying the configuration files and executing the command kill -HUP 1, you add a new terminal without rebooting the system or otherwise interrupting the system's normal operation.
On most System V-based systems, the telinit q command performs the same function. Under HP-UX and Tru64, use init q instead (unless you've created a link named telinit).
After you execute this command, check the new terminal. It should have a login prompt and allow you to log in normally. Sorting out terminal line problems is the topic of the next section.
12.3.4 Terminal Handling Under Solaris
With Solaris, terminal lines are handled in a very different manner. The Service Access Facility (SAF) controls terminal lines and remote printing under Solaris (it is derived from the System V.4 standard). The seeming complexity of the SAF can be somewhat intimidating initially, but it is more verbose than truly complicated. The SAF has the potential to manage vast areas of system capabilities, but in fact, in its present form, what it does is really quite limited. We'll attempt to demystify its workings here.
22.214.171.124 Structure of the Service Access Facility
The Service Access Facility (SAF) is organized in the following hierarchy:
Multiple instances of a port monitor may be present. For example, there will be one ttymon process on the system for each serial port managed by the SAF.
The following commands are used to configure the SAF and its serial port monitors:
126.96.36.199 Port monitors
The sacadm -l command lists port monitors currently administered by the sac daemon:
# sacadm -l PMTAG PMTYPE FLGS RCNT STATUS COMMAND zsmon ttymon - 0 ENABLED /usr/lib/saf/ttymon #
This output illustrates more of the structure implicit in the SAF. The PMTAG field shows the name assigned to a particular defined instance of a port monitor. If that sounds like gibberish, the following may help. The term "port monitor" is used somewhat promiscuously in the Solaris documentation. There are three kinds of entities that might be referred to as port monitors, depending on the context:
Sun recommends creating a PMTAG for each block of serial ports with its own separate controller. The sacadm command may be used to create a new PMTAG. For example, this command creates mux0 as a ttymon-type port monitor:
# sacadm -a -p mux0 -t ttymon -c /usr/lib/saf/ttymon \ -v `ttyadm -V` -y "MUX 0 ttymon" -n 9999
The options to sacadm used in the preceding example have the following meanings:
The command creates a subdirectory of /etc/saf named mux0; the pmadm command would be used to create actual port monitors associated with this PMTAG.
The pmadm -l command may be used to list all port monitors for a given PMTAG:
$ pmadm -l -p zsmon Use -L for a compact format. PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> zsmon ttymon ttya u root /dev/term/a I - /usr/bin/login - 38400 ldterm,ttcompat ttya login: - tvi925 n # Bidir. Modem zsmon ttymon ttyb u root /dev/term/b - - /usr/bin/login - 9600 - ttyb login: - tvi925 - # Terminal
On this system, the zsmon PMTAG includes two ttymon port monitors: ttya and ttyb, controlling /dev/term/a and /dev/term/b, respectively. ttya is used for a bidirectional (dial-in/dial-out) modem, and ttyb controls a terminal.
188.8.131.52 Creating port monitors with pmadm
The following pmadm command could be used to create the port monitor for /dev/term/b:
# pmadm -a -p zsmon -s ttyb -i root -f u -v `ttyadm -V` \ -m "`ttyadm -d /dev/term/b -T vt100 -s /usr/bin/login \ -l 57600 -p \"ttyb login: \"`"
Since pmadm is a complicated and completely general port monitor administration utility, Solaris provides some auxiliary commands to help generate its required input. The auxiliary command for serial lines is ttyadm.
Let's take the preceding command apart:
pmadm -a Add a port monitor. -p zsmon Port monitor tag. -s ttyb Service tag (conventional name is shown). -i root Run service (specified below) as this user (root). -f u Create utmp entry for port (required by login). -v `ttyadm -V` Version (determined/returned by ttyadm). -m "`ttyadm ...`" Port monitor-specific data, formatted by ttyadm: ttyadm -d /dev/term/b Special file for port. -T vt100 Terminal type (defined in the terminfo database). -s /usr/bin/login Service program. -l 57600 Line type (entry label in /etc/ttydefs). -p \"ttyb login: \" Login prompt (protect quotes with backslashes).
This command adds (-a) the port controlled by the special file /dev/term/b (-d to ttyadm) to the port monitor zsmon's control (-p). The pmadm command uses the ttyadm command twice to format its input correctly: the output of ttyadm is placed into the pmadm command via back quotes. The second ttyadm command does most of the work. It specifies that the /usr/bin/login service will execute at that port when connection is requested (ttyadm -s); the login prompt will be:
The terminal line's configuration corresponds to the entry labeled 57600 in the /etc/ttydefs file (ttyadm -l).
The command for a bidirectional modem line is similar (the changes are in boldface):
# pmadm -a -p zsmon -s ttya -i root -f u -v `ttyadm -V` \ -m "`ttyadm -d /dev/term/a -T vt100 -s /usr/bin/login \ -l 57600E -p \" login: \" \ -b -S n -t 30 -m ldterm,ttcompat`"
The second ttyadm command uses these additional options:
To change a port monitor definition, you must remove the old one first, using pmadm -r, and then use pmadm -a to add a correctly configured one.
184.108.40.206 The ttydefs file
The configuration file used by ttymon is /etc/ttydefs . It is viewed and maintained by the sttydefs command. ttydefs holds essentially the same data as gettydefs; the sttydefs interface is an attempt to provide continuity across any future file format changes.
Here are some sample entries from /etc/ttydefs:
57600E:57600 hupcl:57600 hupcl::57600E 57600:57600 hupcl evenp:57600 evenp::38400 38400:38400 hupcl evenp:38400 evenp::19200 19200:19200 hupcl evenp:19200 evenp::57600
The first entry specifies a line fixed at 57600 baud. The remaining lines form a cycle for an autobaud modem (the hupcl attribute tells the line to hang up when a connection terminates and the evenp attribute select even parity).
The sttydefs -l command may also be used to view the available line definitions. Here is the output corresponding to the first sample entry above:
$ sttydefs -l 57600E -------------------------------------------- 57600E:57600 hupcl evenp:57600 evenp::57600E -------------------------------------------- ttylabel: 57600E initial flags: 57600 hupcl evenp final flags: 57600 evenp autobaud: no nextlabel: 57600E
The sttydefs command has two other main options, -a and -r, which add and remove entries from the /etc/ttydefs file, respectively. When adding an entry, the following additional options are available:
The next label, initial flags (terminal settings set prior to login), and final flags (terminal settings after login) have the same meanings as they do in the /etc/ttydefs file, but their use has been greatly expanded. Any flags accepted by the stty command are accepted in this field, separated by spaces. The -a and -r options require and the -l option accepts a label for the /etc/ttytab entry.
For example, the following commands add a new entry named 57600i and delete an entry named 1200 from the /etc/ttydefs file:
# sttydefs -a 57600i -n 57600i -i "57600 erase ^h" \ -f "57600 sane crt erase ^?" # sttydefs -r 1200
220.127.116.11 Using admintool to configure serial lines
admintool can be used to perform the same configuration steps we have just done manually. Figure 12-4 illustrates the dialog it provides for performing this task.
Figure 12-4. Configuring a serial line with admintool
The tool provides three configuration modes basic, more, and expert which provide access to successively more attributes. It also provides a series of templates: predefined collections of settings designed for specific purposes. The figure illustrates those designed for a bidirectional modem.
Most of the fields are self-explanatory. The only tricky one is labeled Baud Rate. It is used to select an entry within /etc/gettydefs, rather than specifying a literal baud rate.