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


Direction (DTE DCE)


Frame Ground (FG)



Transmit Data (TD)



Receive Data (RD)



Request to Send (RTS)



Clear to Send (CTS)



Data Set Ready (DSR)



Signal Ground (GND)



Data Carrier Detect (DCD)



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 (DTEfigs/u2194.gifDCE), 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 (DTEfigs/u2194.gifDTE) 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. 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 figs/u00b1.gif5 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






I want to call another system. Are you ready?



I'm ready. Go ahead and dial.



I've got your party.



Can I send data now?



Sure. Go ahead.


TD ...

Data sent out.


... RD

Data received.



Hold on for a moment!



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.



I'm done. Please hang up.



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.

Some publications suggest that you can fake out pins 4 and 5 by tying them together at each end of the cable. As a result, whenever the computer looks for a go-ahead signal, it gets it from itself. This is really a poor practice. It will generally work if you are simply connecting terminals, since people cannot type fast enough ever to require the computer to "cry uncle." Nevertheless, there can be problems. For example, a function key programmed to send a long string of characters or a PC trying to upload a file can send too fast for a loaded system to capture all the characters. Dropped characters can result, unless the system can rely on the flow-control handshake.

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.[8] The cables pictured are the following, from left to right:

[8] http://www.cablestogo.com/resources/connector_guide.asp is a very useful guide to cable connectors and contains excellent illustrations of the full range of cable types for computer devices.

  • USB Type-B and Type-Aconnectors (both male). USB is discussed in the final section of this chapter.

  • DB-9 connector (female), a 9-pin cable commonly used for connecting devices to computer serial ports.

  • DB-25 connector (male), containing the full 25 pins.

  • 8-pin mini DIN connector (male), a connector type used for serial ports on older Macintosh systems.

  • RJ-12 modular plug containing 6 wires. RJ-45 (8-wire) plugs are also used for serial devices (as well as for network cables).

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.

Table 12-5. Serial cable pin correspondences




Mini DIN




























4, 8









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:

  • The appropriate special file.

  • If the device is a terminal, the name of the corresponding termcap or terminfo entry.

  • Other line and device characteristics needed by the various configuration files. The most crucial of these is the line speed (or maximum device speed, whichever is determinant).

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[9] facility for handling serial lines. The various versions are treated separately.

[9] Not that anyone else would want it . . . FreeBSD configuration files

In addition to the termcap file, FreeBSD uses the following configuration files for terminal lines:


Lists serial lines in use and their characteristics


Holds generic serial line definitions

/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:


Special filename in /dev that communicates with this serial line.


The command that init should execute to monitor this terminal line. For terminals and modems, the program used is getty. If init should not create a process to monitor this line, this field should contain the keyword none. This is the case for pseudo terminals and for serial lines where no one will log in: printers, terminals used purely as displays, and the like. Use a full pathname for all commands, and enclose commands containing spaces in quotation marks.


For serial lines that support user logins, the name of a terminal type described in /etc/termcap. If a terminal type is included, the TERM variable will be set to this value at login. Alternatively, the field can contain the keyword network (for pseudo terminals) or dialin (for dial-up modems); such keywords can be used by user initialization files or the tset command.[10]

[10] What I'm calling keywords have termcap entries like the following:


Zero or more keywords, separated by spaces. The following keywords are supported:


Line is enabled, and command will be run by init.


Line is disabled, and the entry is ignored. No getty process is created.


Allow root logins.

window= cmd

init should run cmd before the one in field 2.

group= name

Used to define named groups of teminal for use the /etc/login.conf file (see Section 6.2).

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


System initialization configuration file


Terminal line definition file

The lines in /etc/inittab to start getty processes look like this:

cons:0123456789:respawn:/usr/sbin/getty /dev/console t1:234:respawn:/usr/sbin/getty /dev/tty0
cons:123456:respawn:/usr/sbin/getty console console t1:234:respawn:/usr/sbin/getty -h tty0p1 57600
1:2345:respawn:/sbin/mingetty --noclear tty1 t1:234:respawn:/sbin/mgetty -D -i /etc/issue -s 57600 ttyS1
cons:1234:respawn:/usr/sbin/getty console console vt100 t1:234:respawn:/usr/sbin/getty /dev/tty00 57600 vt100

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:

  • The AIX version of getty does not use the gettydefs or the second getty parameter (configuration data is stored in the ODM database). It requires the full pathname to the special file as its sole argument.

  • The -h option on the HP-UX version tells getty not to force a hang up on the terminal line before initializing it.

  • Linux systems do not define a console device in the usual way. Instead, one or more virtual console sessions are defined for use when the console is used as a terminal (rather than as a graphical workstation). The --noclear option to the mingetty command says not to clear the screen before issuing a login prompt. This command is a minimal implementation of getty used only in this context.

  • Linux offers several getty-type commands for use with terminal lines and modems. I prefer mgetty, and recent Red Hat and SuSE distributions finally agree with me. Its -D option says the line is a data line, i.e., there is no fax machine on the line (-F says the opposite). The -i option specifies an alternate, shorter text file to be displayed before the login prompt, a step always appreciated by users of slower modems. Finally, -s specifies the line speed. The final command line item is mgetty's required parameter: the name part of the device file.

  • The Tru64 getty command uses a third parameter specifying the terminal type for that terminal line.

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


Baud rate of n baud.


Local directly connected line.


Hang up on close (useful for modems).


Tabs are sent to the terminal as spaces.


Set various parameters to reasonable values (as in stty).

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

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 The Linux mgetty configuration files

mgetty uses several configuration files stored in /etc/mgetty+sendfax:


Main mgetty configuration file (entries common to data and fax lines).


Specifies programs to be run by connection type. The default version of this file is usually quite adequate; simply uncomment the entries applying to the types of connections you will support. The /bin/login entry is typically used for dial-up lines.


Accept/reject incoming calls based on Caller ID.


If this file exists, the corresponding line is disabled. 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.

Solaris provides a graphical tool for interfacing with the SAF. It does make setting things up a lot easier and more automated. However, in this section, we'll be looking at the underlying commands first, so that the concepts and procedures are clear. Structure of the Service Access Facility

The Service Access Facility (SAF) is organized in the following hierarchy:

  • At the top level is the Service Access Controller (SAC), which oversees the entire facility. The sac daemon is started in /etc/inittab by an entry like this one:

    sc:234:respawn:/usr/lib/saf/sac -t 300

    The -t option to the sac command specifies how often the daemon polls the port monitors it controls (in seconds).

  • The SAC starts and controls various port monitors: processes responsible for monitoring one or more ports and connecting requests that arrive on them with the proper system process. sac starts all of the port monitors listed in its configuration file, /etc/saf/_sactab , when it begins executing.

    Currently, there are two different port monitors: ttymon , which is responsible for terminal lines, and listen. The latter was designed to be responsible for managing general network services, but it is really capable of handling only remote printing in the present implementation.[11] On many systems, it is not used at all.

    [11] An amusing comment in /etc/init.d/inetsvc attests to this fact when it explains why the main TCP/IP networking daemon, inetd, is started with the -s option:

  • Port monitors connect requests to local system services. For example, ttymon connects incoming requests on serial lines to the login service and the login program.

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:


High level SAF configuration: add, delete, enable, disable, start, and stop port monitors.


Configure port monitor services (and associated processes) for individual ports.


Helper utility formats input to pmadm for serial ports.


Create and modify entries in /etc/ttydefs describing terminal line characteristics. 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:

  • Port monitor types, of which there are only two: ttymon and listen. The fact that these are also the names of the executable commands for individual port monitor processes is one major source of confusion.

  • Port monitor tags (PMTAG), which define groups of one or more actual port monitor processes (whether or not they are all actually running at any given time). By default, there is only one defined tag per port monitor type: zsmon for ttymon (named for the Zilog serial ports used on Sun CPU boards), and tcp for listen (in the United States, anyway). However, it is possible to have more than one PMTAG per port monitor type; we'll look at how one might be created shortly.

  • Actual port monitor processes, each handling a single port (or request source in the case of network printing requests). The port monitor processes for a given port monitor tag are defined in the file /etc/saf/pmtag/_pmtab (for example, /etc/saf/zsmon/_pmtab), which is maintained by the pmadm command. ttymon port monitors run the ttymon command, and listen port monitors run the listen command. Individual port monitors are identified by service tags (SVCTAG).

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:


Add a port monitor.


Specify port monitor type (ttymon or listen).


Specify PMTAG.


Specify command to run for associated port monitor processes.


Specify version number (returned by the command ttyadm -V).


Description for _pmtab entry.


Number of times to restart port monitor if it dies.

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:[12]

[12] The -t and -s options may be used with pmadm -l to list port monitors of a given type or with a specified SVCTAG, respectively.

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

ttyb login:

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:


Designates a bidirectional modem line.

-S n

Set software carrier off.

-t 30

Login timeout period (seconds).

-m ldterm,ttcompat

Additional STREAMS modules to load (required for modems).

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


Next label.


Initial flags.


Final flags.


Set autobaud on terminal line.

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

Essential System Administration
Essential System Administration, Third Edition
ISBN: 0596003439
EAN: 2147483647
Year: 2002
Pages: 162

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net