Terminal Lines and Modem Control

It is also fair to say that modems have never been a real UNIX concern. Once networking boomed, and UNIX so successfully merged with networking, modems were pushed even more to the side. UNIX focused on providing basic network services, and a network connection became an integral part of each UNIX system. Modems are more attractive for the desktop side where UNIX never dominated. It does not mean that UNIX has completely ignored modem topics; each UNIX flavor provides some kind of modem control. It also gave a chance to third−party developers to fill the existing gap, providing needed software widely implemented on all UNIX platforms.

24.2 UNIX Modem Control

The lack of a general UNIX approach to control modems resulted in many different, flavor−specific solutions. In an early UNIX phase, solutions were based on flexible UNIX organization and existing functions of a similar nature and purpose; later, each flavor introduced some kind of modem−related commands and sometimes modem control relays on the third−party UNIX upgrade. We briefly discuss all three listed approaches.

24.2.1 Terminal Lines and Modem Control

This approach probably belongs to history, but it is illustrative to understand a conflicting situation in attaching a general−purpose bidirectional modem to a dedicated serial terminal line. It is important to understand that the obstacle is not the used serial port the implemented hardware itself allows bidirectional serial communication, but rather the existing control software, primarily the invoked getty program on the terminal line at system startup. UNIX provided different flavor−colored solutions for this problem. SunOS has a mechanism that allows a serial port to be used in both directions; the driver supports two entry points, one for each direction. For each terminal line identified by the device tty0–tty127, the existing driver is monitoring for DCD data carrier detect signal and puts up a getty program. Devices with minor numbers 128–255 by convention named cu0–cu127 refer to the same physical devices but allow the device to be opened even when DCD is not present. The net effect is that a modem can be attached to a terminal line ttyn by convention usually renamed to ttydn and used for dial−in, but also used for dial−out when referred to by the name cuan. The administrator should create two different special files for the terminal line to which the modem is attached; for dial−in — devttydn n = modem line number and for corresponding dial−out — devcuan. The dial−in device devttydn would be entered as a normal entry in the terminal line configuration file etcttytab. The two special files differ only in their minor device numbers subtype within device class, with an offset of 128 could be seen by the ls −l command. To create these special files, the mknod command is used, as for any other device. Here is an example: mknod devttyd1 c 12 1 mknod devcua1 c 12 129 Two character special files for the class 12 terminal lines are created. The corresponding entries for terminal lines in the etcttytab should be replaced with: 592 ttyd1 usretcgetty d2400 unknown on dialin entry enabled cua1 none unknown off dialout entry disabled Finally, the software carrier detect for the dial−out version of the port should be disabled: ttysoftcar n devcua1 Once it is done, the use of special files etcttyd1 and etccua1 is possible. For more detailed explanations and complete installation, SunOS provides the manual page named zs. System V UNIX flavors specify the terminal line, i.e., serial port initialization, through the etcinittab file. When a modem is attached to the system, the appropriate port must be enabled for duplex communication. It can be done by replacing the getty program in the corresponding inittab−entry with another, more sophisticated program that supports both, getty and duplex communication such programs exist on the System V, for example the program uugetty. An inittab−entry could be: 27:2:respawn:usrlibuucpuugetty −r tty12 2400 Another approach is also possible; to invoke the init program to reinitialize the terminal line for dial−in and dial−out, using different init−run−levels for example, 2 and 3. Then, invoking init 2 will initialize the terminal line for dial−in, including the getty program the corresponding inittab−entry with the getty must exist for run−level 2. By invoking init 3, the terminal line will be enabled for dial−out the previous inittab−entry with the getty must be excluded from the run−level 3.

24.2.2 Modem−Related UNIX Commands