1.1. What is a console?

The console is the text output device for system administration messages. These messages come from the kernel, from the init system and from the system logger.

On modern small computers the console is usually the computer's attached monitor and keyboard.

On many older computers the console is an RS-232 link to a terminal such as a DEC VT100. This terminal is in a locked room and is continually observed by the minicomputer's operators. Large systems from Sun, Hewlett-Packard and IBM still use serial consoles.

It is usually possible to login from the console. A login session from the console is treated by many parts of the operating system as being more trustworthy than a login session from other sources. Logging in as the root super-user from the console is the Command Line of Last Resort when faced with a misbehaving system.

1.2. Why use a serial console?

For the average user a serial console has no advantage over a console offered by a directly attached keyboard and screen. Serial consoles are much slower, taking up to a second to fill a 80 column by 24 line screen. Serial consoles generally only support non-proportional ASCII text, with limited support for languages other than English. A new terminal can be more expensive than an old PC.

There are some scenarios where serial consoles are useful. These are:

Unlike minicomputer systems, the IBM PC was not designed to use a serial console. This has two consequences.

Firstly, Power On Self-Test messages and Basic Input/Output System (BIOS) messages are sent to the screen and received from the keyboard. This makes it difficult to use the serial port to reconfigure the BIOS and impossible to see Power On Self-Test errors.

An increasing number of manufacturers of rackable server equipment are altering their BIOSs to optionally use the RS-232 port for BIOS configuration and test messages. If you are buying a machine specifically for use with serial console you should seek this feature. If you have an existing machine that definitely requires access to the BIOS from the serial port then there are hardware solutions such as PC Weasel 2000.

Secondly, the RS-232 port on the IBM PC is designed for connecting to a modem. Thus a null modem cable is needed when connecting the PC's serial port to a terminal.

1.3. Alternative meanings of "console"

Some authors use the word "console" to refer to the keyboard and monitor that are attached to the system unit. This is described as a "physical console" by some Linux documentation. The console where system messages appear is described as the "logical console" by that documentation.

As an illustration of the difference, X Windows should start on the physical console but system messages issued by failures when starting X Windows should be written to the logical console.

To avoid confusion this HOWTO uses the word "console" to describe the place where system messages are printed. This HOWTO uses the phrase "attached monitor and keyboard" rather than the confusing words "physical console".

These distinctions are also made in the naming of devices. The device /dev/console is used to send messages to the console. The symbolic link /dev/systty points to the device which is used by the attached monitor and keyboard, often /dev/tty0.

1.4. Configuration overview

There are five major steps to configuring a serial console.

Examples in this HOWTO are from Red Hat Linux versions 7.1 through to 7.3 (released 2001 through to 2002). The maintainer would appreciate updates when new versions of Red Hat Linux appear. The maintainer would very much appreciate examples for Linux distributions that are dissimilar to Red Hat Linux; particularly Debian GNU/Linux and Slackware Linux. All contributors are acknowledged in Section G.3.

2.1. Create fallback position

Good system administrators always have a viable fallback plan to cope with failures. A mistake configuring the serial console can make both the serial console and the attached monitor and keyboard unusable. A fallback plan is needed to retrieve console access.

Many Linux distributions allow boot diskettes to be created. Writing a boot diskette before altering the console configuration results in a boot diskette that passes good parameters to the kernel rather than parameters that may contain an error.

Under Red Hat Linux a boot diskette is created by determining the running kernel version

bash$ uname -r
2.4.2-2

and then using that version to create the boot diskette

bash# mkbootdisk --device /dev/fd0 2.4.2-2

Under Debian GNU/Linux the boot diskette is created by determining the version of the running kernel and then using that version to write the boot diskette

bash# mkboot /boot/vmlinuz-2.4.2-2

An alternative fallback position is have a rescue diskette with the machine. A common choice is Tom's root boot.

2.2. Select a serial port

# Disable /dev/ttyS2 so interrupt 4 is not shared,
# then /dev/ttyS0 can be used as a serial console.
setserial /dev/ttyS2 uart none port 0x0 irq 0

2.3. Select a serial speed and parameters

This HOWTO does not discuss the RS-232 standard, which is formally known as ANSI/TIA/EIA-232-F-1997 Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Data Interchange. For an explanation of "bits per second", "start bits", "data bits", "parity", "stop bits" and "flow control" refer to the Serial-HOWTO and the Modem-HOWTO.

The description of the command syntax for setting the serial parameters in the kernel, boot loaders and login applications uses the following variables which describe RS-232 parameters.

At present the RS-232 status lines are ignored by the kernel. A kernel message will be printed even if Data Carrier Detect and Data Set Ready are not asserted. This leads to the kernel messages being sent to a modem which is idle and in command mode.

The console's slack interpretation of CTS, DSR and DCD makes it impossible to connect a serial console to an RS-232 multi-drop circuit. Multi-drop circuits have more than two computers on the circuit; they are traditionally four-wire, satelite or wireless services.

The Linux kernel uses the syntax in Figure 2-7 to describe the serial parameters. Many boot loaders use a variation of the syntax used by the Linux kernel.

Note that <mode> does not include <stop>. The kernel assumes the number of stop bits to be one. This shortcoming needs to be considered when deploying long RS-232 cables.

Most boot loaders default to 9600n8. A common default found on older terminals is 9600e7.

Use 9600n8 if possible, as this is the default for most Linux software and modern devices.

This HOWTO always configures the serial speed and parameters, even where not strictly necessary. This is so that people configuring parameters other than the recommended and common default value 9600n8 will know what to alter.

2.4. Configure the modem or the null-modem cable

If a modem is used, configure it to be a dumb modem at the port speed selected in Section 2.3. If the modem accepts Hayes AT commands see Chapter 12 to dumb-down the modem.

Alternatively if a terminal and a null-modem cable are used see Section 11.3, which discusses the pinout of the null modem cable.

2.5. Configure the terminal or the terminal emulator

Configure the terminal to match the serial parameters. The data bits, parity bits and stop bits must match. If a modern "smart" modem is used then the bit speeds need not match. If a dumb modem or a null modem cable is used then the bit speeds must match.

Set CTS/RTS handshaking on, DTR/DSR handshaking off and XON/XOFF handshaking off. Your equipment may call CTS/RTS handshaking or DTR/DSR handshaking "hardware handshaking" and may call XON/XOFF handshaking "software handshaking".

Set automatic line wrapping on. This allows all of a long console message to be read.

Set the received end of line characters to CR LF (carriage return then line feed). Set the transmitted end of line characters to just CR (carriage return).

If you are using a terminal emulator then it is best to choose to emulate the popular DEC VT100 or VT102 terminal. Later terminals in the DEC VT range are compatible with the VT100. If this terminal is not available then try to emulate another terminal that implements ANSI X3.64-1979 Additional Controls for Use with American National Standard Code for Information Interchange (or its successor ISO/IEC 6429:1992 ISO Information technology — Control functions for coded character sets). For example, many emulators have a terminal called ANSI BBS which uses the IBM PC character set, the 16 IBM PC colors, a 80 column by 25 line screen and a selection of X3.64-1979 control sequences.

See the Text-Terminal-HOWTO for much more information on configuring terminals.

4.1. Configure the LILO boot loader

LILO is the Linux Boot Loader used on Intel machines. Other boot loaders for Intel machines exist, common alternatives are GRUB and SYSLINUX. Equivalents to LILO exist for other processor architectures, their names are usually some play upon "LILO".

LILO is documented in the lilo(8) and lilo.conf(5) manual pages; the LILO Generic boot loader for Linux … User's Guide found in the file /usr/share/doc/lilo…/doc/User_Guide.ps; and the LILO mini-HOWTO.

The LILO configuration is kept in the file /etc/lilo.conf. The first part of the file applies to all images. The following parts are image descriptions for each kernel.

Set LILO to use the serial port. The syntax of the serial line parameters follows that used by the kernel.

Where the variables are the same as used by the kernel (shown in Figure 2-7) and:

Our examples use /dev/ttyS0, which LILO knows as port 0.

serial=0,9600n8
timeout=100
restricted
password=PASSWORD

The parameters restricted and password are used to avoid someone dialing in, booting the machine, and stepping around the Linux access permissions by typing:

LILO: linux init=/sbin/sash

The password should be good, as it can be used to gain root access. The LILO password is stored in plain text in the configuration file, so it should never be the same as any other password. The permissions on the configuration file should be set so that only root can read /etc/lilo.conf.

bash# chmod u=rw,go= /etc/lilo.conf

LILO has an option to display a boot message. This does not work with serial consoles. Remove any lines like:

message=/boot/message

LILO is now configured to use the serial console. The kernels booted from LILO are yet to be configured to use the serial console.

4.2. Configure the GRUB boot loader

GRUB is a boot loader designed to boot a wide range of operating systems from a wide range of filesystems. GRUB is becoming popular due to the increasing number of possible root filesystems that can Linux can reside upon.

GRUB is documented in a GNU info file. Type info grub to view the documentation.

The GRUB configuration file is /boot/grub/menu.lst. Some distributions use another configuration file; for example, Red Hat Linux uses the file /boot/grub/grub.conf.

GRUB configuration files are interpreted. Syntax errors will not be detected until the machine is rebooted, so take care not to make typing errors.

Edit the GRUB configuration file and remove any splashimage entries. If these entries are not removed GRUB 0.90 behaves very oddly, transferring control between the serial console and the attached monitor and keyboard.

If there is not already a password command in the GRUB configuration file then create a hashed password, see Figure 4-4. The password should be good, as it can be used to gain root access.

grub> md5crypt
Password: **********
Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.

Use that hashed password in the GRUB configuration file, this is shown in Figure 4-5.

password --md5 $1$U$JK7xFegdxWH6VuppCUSIb.

Define the serial port and configure GRUB to use the serial port, as shown in Figure 4-6.

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal serial

--unit is the number of the serial port, counting from zero, unit 0 being COM1.

Note that the values of --parity are spelt out in full: no, even and odd. The common abbreviations n, e and o are not accepted.

If there is mysteriously no output on the serial port then suspect a syntax error in the serial or terminal commands.

If you also want to use and attached monitor and keyboard as well as the serial port to control the GRUB boot loader then use the alternative configuration in Figure 4-7.

password --md5 $1$U$JK7xFegdxWH6VuppCUSIb.
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

When both the serial port and the attached monitor and keyboard are configured they will both ask for a key to be pressed until the timeout expires. If a key is pressed then the boot menu is displayed to that device. Disconcertingly, the other device sees nothing.

If no key is pressed then the boot menu is displayed on the whichever of serial or console is listed first in the terminal command. After the timeout set by the timeout the default option set by default is booted.

Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.

    GRUB  version 0.90  (639K lower / 162752K upper memory)

 +-------------------------------------------------------------------------+
 | [ Red Hat Linux (2.4.9-21)   ]                                          |  
 |                                                                         |
 |                                                                         |
 +-------------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS or 'p' to enter a
      password to unlock the next set of features.

   The highlighted entry will be booted automatically in 10 seconds.

If you are not using a VT100 terminal then the cursor keys may not work to select a GRUB menu item. The instructions shown in Figure 4-8 are literally correct: Use the ^ and v keys means that the caret key (Shift-6) moves the cursor up and letter vee key (V) moves the cursor down.

Note when configuring GRUB that there are two timeouts involved. Press any key to continue is printed for terminal --timeout=10 seconds, waiting for someone on the keyboard or terminal to press a key to get the input focus. Then the menu is displayed for timeout 10 seconds before the default boot option is taken.

If the terminal attached to the serial port is not a real or emulated VT100, then force GRUB to use it's command line interface. This interface is much more difficult to use than GRUB's menu interface; however, the command line interface does not assume the VT100's terminal language.

terminal --timeout=10 --dumb serial console

This HOWTO does not discuss the use of GRUB's command line. It is far too complex and error-prone to recommend for use on production machines. Wizards will know to consult GRUB's info manual for the commands required to boot the kernel.

GRUB's menu's can be edited interactively after P is pressed and the password supplied. A better approach is to add menu items to boot the machine into alternative run levels. A sample configuration showing a menu entry for the default run level and an alternative menu entry for single user mode (run level s) is shown in Figure 4-10. Remember to use the lock command to require a password for single user mode, as single user mode does not ask for a Linux password.

password --md5 $1$U$JK7xFegdxWH6VuppCUSIb.
default 0
title Red Hat Linux (2.4.9-21)
        root (hd0,0)
        kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
        initrd /initrd-2.4.9-21.img
title Red Hat Linux (2.4.9-21) single user mode
        lock
        root (hd0,0)
        kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 s
        initrd /initrd-2.4.9-21.img

File names in the kernel and initrd commands are relative to the GRUB installation directory, which is usually /boot/grub. So /vmlinuz-2.4.9-21 is actually the file /boot/grub/vmlinuz-2.4.9-21.

GRUB is now configured to use the serial console. The kernels booted from GRUB are yet to be configured to use the serial console.

4.3. Configure the SYSLINUX boot loader

SYSLINUX is a boot loader that is installed on a MS-DOS floppy disk. As directed by it's configuration file \SYSLINUX.CFG it will load one of the files from the floppy disk as a Linux kernel.

SYSLINUX presents a simple text interface that can be used to select between canned configurations defined in the configuration file and can be used to add parameters to the kernel.

ISOLINUX and PXELINUX are variants of SYSLINUX for CD-ROMs and Intel's Preboot Execution Environment.

SYSLINUX supports a variety of serial port speeds, but it only supports eight data bits, no parity and one stop bit. SYSLINUX supports the serial ports COM1: through to COM4:, as with most boot loaders these are written as port 0 through to port 3.

For SYSLINUX to support a serial console add a new first line to \SYSLINUX.CFG:

The variables are the same as used by syntax descriptions in Figure 2-7 and Figure 4-2 plus those in Figure 4-12.

The <syslinux_flow_control> variable controlling the RS-232 status and flow control signals is optional. If your null-modem cable does not present any status or handshaking signals then do not use it. The value of <syslinux_flow_control> is calculated by adding the hexadecimal values for the desired flow control behaviours listed in Table 4-1.

The behaviours for a correctly-wired null-modem cable or a correctly configured modem are marked "Required for full RS-232 compliance" in the table. The sum of these values is 0xab3.

Our preferred configuration of 9600bps, port 0, full RS-232 status signals and CTS/RTS flow control is written as:

serial 0 9600 0xab3

When using this configuration SYSLINUX will not display anything and will not accept any typed character until the RS-232 status signals show a connected modem call (or a connected terminal if you are using a null-modem cable).

If you have a null modem cable with no RS-232 status signals and no flow control then use:

serial 0 9600

Remember that the serial command must be the first line in \SYSLINUX.CFG.

5.1. Configure Linux kernel using LILO

For each image entry in /etc/lilo.conf add the line:

append="console=tty0 console=ttyS0,9600n8"

Sometimes the append line will already exist. For example

append="mem=1024M"

In this case, the existing append line is modified to pass all the parameters. The result is:

append="mem=1024M console=tty0 console=ttyS0,9600n8"

As a complete example, a typical /etc/lilo.conf configuration from Red Hat Linux 7.1 is:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
default=linux

image=/boot/vmlinuz-2.4.2-2
  label=linux
  read-only
  root=/dev/hda6
  initrd=/boot/initrd-2.4.2-2.img

This is modified to

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
default=linux
# Changes for serial console on COM1: in global section
#   Deleted: message=/boot/message
serial=0,9600n8
timeout=100
restricted
password=de7mGPe3i8

image=/boot/vmlinuz-2.4.2-2
  label=linux
  read-only
  root=/dev/hda6
  initrd=/boot/initrd-2.4.2-2.img
  # Changes for serial console on COM1: in each image section
  append="console=tty0 console=ttyS0,9600n8"

Now that we have finished configuring LILO, use the lilo command to install the new boot record onto the disk:

bash# chown root:root /etc/lilo.conf
bash# chmod u=rw,g=,o= /etc/lilo.conf
bash# lilo
Added linux *

5.2. Configure Linux kernel using GRUB

Find each title entry in the GRUB configuration file. It will be followed by a kernel line. For example

title Red Hat Linux (2.4.9-21)
  root (hd0,0)
  kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
  initrd /initrd-2.4.9-21.img

Modify each of the kernel lines to append the parameters that inform the kernel to use a serial console.

title Red Hat Linux (2.4.9-21)
  root (hd0,0)
  kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8
  initrd /initrd-2.4.9-21.img

As a complete example, Example 5-3 is a typical GRUB configuration from Red Hat Linux 7.2.

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
password --md5 $1$wwmIq64O$2vofKBDL9vZKeJyaKwIeT.
title Red Hat Linux (2.4.9-21)
root (hd0,0)
  kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
  initrd /initrd-2.4.9-21.img

The modified configuration file is shown in Example 5-4.

default=0
timeout=10
password --md5 $1$wwmIq64O$2vofKBDL9vZKeJyaKwIeT.
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Linux (2.4.9-21)
  root (hd0,0)
  kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8
  initrd /initrd-2.4.9-21.img
title Red Hat Linux (2.4.9-21) single user mode
  lock
  root (hd0,0)
  kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8 s
  initrd /initrd-2.4.9-21.img

5.3. Configure Linux kernel using SYSLINUX

Edit each LABEL entry to add an APPEND line containing the serial console parameter to pass to the Linux kernel. Like LILO, if a kernel already has parameters, then add our parameters to the list after APPEND.

For example:

APPEND console=tty0 console=ttyS0,9600n8

There are some traps for beginners in the differences between LILO and SYSLINUX. LILO uses append=, whereas SYSLINUX uses just append. lilo needs to be run after each change to /etc/lilo.conf, whereas syslinux does not need to be run after changing \SYSLINUX.CFG.

6.1. init system

The file /etc/inittab contains the background programs that used to keep the system running. One of these programs is one getty process per serial port.

co:2345:respawn:/sbin/getty ttyS0 CON9600 vt102

Each field in inittab is separated by a colon and contains:

After changing /etc/inittab restart init with

telinit q

An alternative is to send the hangup signal to init with the command kill -HUP 1. This is not recommended: if you make a typing mistake and actually kill init then your system will suddenly halt.

	Comments in inittab and Red Hat's kudzu
	kudzu uses the # line comment to activate and deactivate the gettys for the attached monitor and keyboard and for the serial port. To prevent a genuine comment from becoming confused with a line saved by kudzu use ## at the start of a line of genuine comments.

6.2. Traditional getty

Traditional getty implementations include uugetty and getty_ps.

The traditional getty is listed in /etc/inittab with the name of a section in /etc/gettydefs to use for its configuration. Our example in Figure 6-3 used the section CON9600.

There is no CON9600 in the standard gettydefs. This is deliberate, as serial consoles sometimes require slight tweaking. Copy the DT9600 entry and use it as your model.

# Serial console 9600, 8, N, 1, CTS/RTS flow control
CON9600# B9600 CS8 -PARENB -ISTRIP CRTSCTS HUPCL # B9600 SANE CS8 -PARENB -ISTRIP CRTSCTS HUPCL #@S @L login: #CON9600

Separate each line with a blank line.

Each configuration line has the syntax:

The <label> is referred to on the getty command line.

The <next_label> is the definition used if a RS-232 Break is sent. As the console is always 9600bps, this points back to the original label. See Section 9.9 if you ever intend to have more one line for CON9600 in gettydefs.

<initial_flags> are the serial line parameters used by getty. These are modeled on the stty(1) and termios(3) options and the full list varies depending upon your getty variant. The parameters in Figure 6-4 ensure that a line at 9600bps with eight data bits and no parity is configured.

<final_flags> are the serial line parameters set by getty before it calls login. You will usually want to set a 9600bps line, SANE terminal handling, eight data bits, no parity and to hang up the modem when the login session is finished.

The <login_prompt> for serial lines is traditionally the name of the machine, followed by the serial port, followed by login: and a space. The macro that inserts the name of the machine and the serial port varies, see the documentation for your getty.

6.3. agetty

agetty is an "alternative getty". It takes all of its parameters on the command line, with no use of /etc/gettydefs or any other configuration file. agetty is documented in the manual page agetty(8).

Figure 6-6 shows how to invoke agetty for use with a serial console.

co:2345:respawn:/sbin/agetty -h -t 60 ttyS0 9600 vt102

ttyS0 refers to the serial device /dev/ttyS0.

9600 is the bits per second of the serial link. agetty will support multiple values, using the modem's CONNECT message or the RS-232 Break signal to select between them. Only use one value, as serial consoles only have only one data rate.

vt102 sets the TERM environment variable to indicate that a VT100 terminal is connecting.

-h activates CTS/RTS handshaking.

-t 60 allows 60 seconds for someone to attempt to log in before the modem is hung up. You should test this feature to ensure that init is not restarting agetty every 60 seconds when the link is idle. Look for a continually changing process identifier for agetty.

agetty uses escape sequences in /etc/issue to insert information. For example, \n.\o \l will appear as remote.example.edu.au ttyS0.

When you log out agetty does not appear to lower the Data Terminal Ready signal to force the modme to hang up. If having people automatically disconnected at the end of their login session matters to you then you might consider mgetty instead.

6.4. mgetty

mgetty is a modem-aware getty. It supports modems with the Hayes AT command set and is especially designed for supporting modems that are used to send faxes and to dial out as well as dial in. These features are not required for a serial console.

mgetty does not require the traditional /etc/gettydefs file. As a result mgetty is invoked from /etc/inittab without supplying an entry in /etc/gettydefs.

co:2345:respawn:/sbin/mgetty ttyS0

mgetty is configured using the file /etc/mgetty+sendfax/mgetty.config. It should contain an entry for the port used by the serial console.

port ttyS0
 speed 9600
 direct yes
 data-only yes
 toggle-dtr yes
 need-dsr yes
 port-owner root
 port-group root
 port-mode 600
 login-prompt @ \P login:\040
 login-time 60
 term vt102

All the options are documented in the PostScript file /usr/share/doc/mgetty…/mgetty.ps.

We set direct, data-only, need-dsr and toggle-dtr so that the RS-232 control lines are used correctly for a dumb modem.

port-owner, port-group and port-mode set the serial device to be accessible only by the root user. Modem applications, which normally use the uucp group, cannot now accidentally use the serial console.

login-prompt shows the machine (@) and serial port (\P) being used. The text \040 is simply the octal code for a space after login:.

term vt102 gives the make and model of the terminal most likely to dial in. This sets the TERM environment variable, which you can change if you are dialling in from another terminal type.

The remaining configuration files, /etc/mgetty+sendfax/dialin.config and /etc/mgetty+sendfax/login.config, do not need to be altered.

If you wish to alter the suggested configuration then note that mgetty's blocking and toggle-dtr parameters do not co-exist well.

If you have difficulties, activate debugging by adding debug 8 to mgetty.config. mgetty's actions are then visible in the file /var/log/mgetty.log.ttyS0.

6.5. mingetty

mingetty is designed to be a minimal getty for the virtual terminals on the workstation's monitor and keyboard. It has no support for serial lines.

You must not use mingetty for the serial line in /etc/inittab, but the current mingetty entries for the virtual terminals can remain.

Each virtual terminal uses about 8KB of kernel memory. If this matters, it is easy to allocate fewer virtual terminals. In the Linux 2.4 kernel virtual terminals are created on demand, so not starting mingetty on the virtual terminal will not create the virtual terminal. If the machine does not have a video card then remove all the mingetty entries from /etc/inittab.

1:2345:respawn:/sbin/mingetty tty1
# Additional virtual terminals are not used
2:2345:off:/sbin/mingetty tty2
3:2345:off:/sbin/mingetty tty3
4:2345:off:/sbin/mingetty tty4
5:2345:off:/sbin/mingetty tty5
6:2345:off:/sbin/mingetty tty6

After restarting init it would be wise to remove the unused device files.

bash# telinit q
bash# deallocvt /dev/tty[2-9] /dev/tty[0-9][0-9]
bash# rm /dev/tty[2-9] /dev/tty[0-9][0-9]

6.6. No getty

If you are using serial console simply to print console messages then do not run a getty process on the serial port.

getty follows a locking convention that prevents other serial port applications from using the serial port. Since we do not want other processes to use the serial port, but are not running getty, manually create the lock file.

Create a file /var/lock/LCK..ttyS0 to contain the text 1. This lets other potential serial port applications know that process 1 has the serial port in use. Process 1 is always the init process, and init is always running, so the serial port is always locked.

The file is created upon each system boot, as lock files are often cleared when the system boots. A convenient place to create the lock file is from /etc/rc.serial. It should contain:

# Lock /dev/ttyS0 as it is used by an output-only console
(umask 022 && \
 rm -f '/var/lock/LCK..ttyS0' && \
 echo '1' > '/var/lock/LCK..ttyS0')

7.1. Allow root to login from serial console

The file /etc/securetty controls the devices that the root user can log in upon.

It is usually desirable to have root be able to log in from the console, so add the basename of the serial console device to /etc/securetty.

ttyS0

Almost anyone can now dial into the modem and attempt to guess the root password. Normally we do not allow root to log in from a remote site, rather we have a normal user log in and then use su or sudo to become root. This gives some traceability.

Unfortunately, the root user needs to be able to log in from the console to fix a full disk. Disk subsystems typically reserve 5% of their space for root's exclusive use.[7] This is enough space for the root user to log in and start deleting the files that filled the disk.

	securetty and Red Hat's kudzu
	kudzu automatically adds the device being used as the console to securetty.

7.2. Change init level to textual

There is little point in running the X Window System on a server with no screen. Edit /etc/inittab finding the line containing initdefault, such as

id:5:initdefault:

Alter the default from run level 5 (multiuser with X Window System) to run level 3 (multiuser).

id:3:initdefault:

The startx command can be used if an occassional X Windows session is required upon an attached keyboard and monitor.

	Run levels and Red Hat's kudzu
	kudzu automatically updates the initdefault entry in inittab to use run level 3 if a serial device is being used as a console.

:0 local /usr/X11R6/bin/X

[servers]
0=/usr/bin/X11/X

7.3. Remove saved console settings

The file /etc/ioctl.save contains the serial and terminal parameters to use in single user mode. The serial and terminal parameters are usually set by getty — during single user mode no getty runs and the contents of /etc/ioctl.save are used to set the serial and terminal parameters.

As we are changing consoles, the saved settings are no longer correct.

bash# rm -f /etc/ioctl.save

We re-create this file once we can log in from the serial console.

7.4. Serial console is not /dev/modem

In many Linux distributions the file /dev/modem is a symbolic link to the serial port containing a modem which is available for use.

Although the serial console is a serial port with a modem, we certainly don't want it used to place an outgoing call.

Check that /dev/modem does not point to the serial port being used for the console, say /dev/ttyS0. If it does, then remove the symbolic link.

bash$ ls -l /dev/modem
lrwxrwxrwx 1 root root 10 Jan 01 00:00 /dev/modem -> /dev/ttyS0
bash# rm /dev/modem

7.5. Alter target of /dev/systty

In many Linux distributions the file /dev/systty is a symbolic link to the device which is used as the by the attached monitor and keyboard. See Section 1.3 for a fuller description.

If there is no attached keyboard and monitor or no wish to give the attached keyboard and monitor greater capabilities then a text terminal, then alter /dev/systty to point to the serial console.

Rather than directly altering this symbolic link, it is better to modify the configuration file used by MAKEDEV, which is then run to recreate the symbolic link. The configuration file is in the directory /etc/makedev.d. The default configuration will point to the first virtual terminal, as shown in Figure 7-6.

l systty tty0

Modify this to point to the serial port being used by the console, as shown in Figure 7-7.

bash# cd /etc/makedev.d
bash# fgrep systty *
linux-2.4.x:l systty tty0
bash# vi linux-2.4.x

l systty ttyS0

Now re-create /dev/systty using its new definition, as shown in Figure 7-8.

bash# cd /dev
bash# rm systty
bash# ./MAKEDEV systty

7.6. Configure Pluggable Authentication Modules

The Pluggable Authentication Module system can be used to give special privileges to users that logged in through the console. It is used to make devices like the floppy disk mountable by the console's user; usually they would need to become the super-user to mount a disk.

The PAM configuration file /etc/security/console.perms contains the <console> variable. For Red Hat Linux 7.1 <console> is the regular expression:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]

Later in the file the <console> user is granted permission to use some devices. This is done by altering the devices' permissions upon login and logout.

<console>  0660 <floppy>     0660 root.floppy
<console>  0600 <sound>      0600 root
<console>  0600 <cdrom>      0660 root.disk
<console>  0600 <pilot>      0660 root.uucp
<console>  0600 <jaz>        0660 root.disk
<console>  0600 <zip>        0660 root.disk
<console>  0600 <ls120>      0660 root.disk
<console>  0600 <scanner>    0600 root
<console>  0600 <camera>     0600 root
<console>  0600 <memstick>   0600 root
<console>  0600 <flash>      0600 root
<console>  0600 <fb>         0600 root
<console>  0600 <kbd>        0600 root
<console>  0600 <joystick>   0600 root
<console>  0600 <v4l>        0600 root
<console>  0700 <gpm>        0700 root
<console>  0600 <mainboard>  0600 root
<console>  0600 <rio500>     0600 root

There are two types of devices listed above: those devices required by someone connecting from an attached keyboard and monitor and those devices that allow convenient access to devices. The configuration file fails to make the distionction between logical and physical console noted in Section 1.3. The configuration file is modified to create that distinction.

<console>  0600 <fb>         0600 root
<console>  0600 <kbd>        0600 root
<console>  0600 <joystick>   0600 root
<console>  0600 <v4l>        0600 root
<console>  0700 <gpm>        0700 root

The remaining devices should be altered to give control only to people attaching from the serial console. For example, we don't want an unprivileged user at a co-location site mounting a floppy disk. Define a new console type for the serial console, say <sconsole>.

<sconsole>=ttyS0

Now modify the remaining entries from <console> to <sconsole>.

<sconsole>  0660 <floppy>     0660 root.floppy
<sconsole>  0600 <sound>      0600 root
<sconsole>  0600 <cdrom>      0660 root.disk
<sconsole>  0600 <pilot>      0660 root.uucp
<sconsole>  0600 <jaz>        0660 root.disk
<sconsole>  0600 <zip>        0660 root.disk
<sconsole>  0600 <ls120>      0660 root.disk
<sconsole>  0600 <scanner>    0600 root
<sconsole>  0600 <camera>     0600 root
<sconsole>  0600 <memstick>   0600 root
<sconsole>  0600 <flash>      0600 root
<sconsole>  0600 <mainboard>  0600 root
<sconsole>  0600 <rio500>     0600 root

7.7. Configure Red Hat Linux

Red Hat Linux stores parameters concerning system start up in the file /etc/sysconfig/init.

Alter the parameter BOOTUP to use terminal-independent commands to write the OK, PASSED and FAILED messages. These messages will no longer appear in green, yellow or red. The comments in /etc/sysconfig/init suggest that any value other than color will do, but it seems that BOOTUP must be set to serial.

Alter the PROMPT parameter to disallow interactive start up. Allowing an unauthenticated keystroke to stop system services is not robust against line noise and allows anyone that dials in during system boot to deny services.

BOOTUP=serial
PROMPT=no

Red Hat Linux runs a hardware discoverer, named kudzu. When attempting to identify a serial port Kudzu resets the serial port. This stops the serial console. Kudzu is configured from the file /etc/sysconfig/kudzu.

Kudzu can be prevented from resetting hardware by setting the configuration parameter SAFE to yes.

SAFE=yes

8.1. Verify console operation

If possible, plug an RS-232 breakout box into the serial port. During reboot the Data Terminal Ready line should become active and then the Transmit Data lights should flash as console messages appear.

Attach a modem, or a null modem cable and a terminal. Configure them to match the serial parameters used by the serial console port. If using a modem, dial in to it from a terminal emulator.

+++
AT Z
AT DT 1234-5678
CONNECT 9600

Configure the terminal or terminal emulator to match the serial parameters used by the serial console. If using a modern Hayes AT-style modem then the speed need not match. If using a directly-attached terminal then the speed must match.

Reboot the computer.

bash# shutdown -r now

During reboot the terminal should see the usual boot loader text, and then the default kernel booting, then the init output, and finally the contents of /etc/issue and getty asking you to login.

LILO:

Linux version …
Kernel command line: auto BOOT_IMAGE=linux ro root=306 BOOT_FILE=/boot/vmlinuz-2.4.3-12 console=tty0 console=ttyS0,9600n8
…
INIT version …
…
/etc/issue says "All your base are belong to us".
remote.example.edu.au ttyS0 login:

If you do not see the login: message then press Return or Enter.

8.2. Re-create saved console settings

Log in as root from the serial console and send the console into single user mode. The modem may hang up whilst doing this and you may need to re-connect.

Without a /etc/ioctl.save containing the saved terminal settings, init assumes a directly attached terminal running at 9600bps with 8 data bits, no parity, 1 stop bit and no flow control. Configure your terminal with these settings.

remote.example.edu.au ttyS0 login: root
Password: …
sh# rm -f /etc/ioctl.save
bash# telinit 1
…Telling INIT to go to single user mode.
INIT: Going single user
INIT: Sending processes the TERM signal
sh# stty sane -parenb cs8 crtscts brkint -istrip -ixoff -ixon

As you use stty to alter the Linux's terminal settings remember to also alter the settings of the attached terminal.

Exiting from single user mode back to the default run level will save the serial console termnial configuration into /etc/ioctl.save.

sh# exit
…
bash# ls -l /etc/ioctl.save
-rw------- 1 root root 60 Jan 1 00:00 /etc/ioctl.save

The terminal settings saved in /etc/ioctl.save will be used if the machine boots into single user mode for any reason.

If your attached terminal or modem cannot alter speed to 9600bps then the above procedure cannot be followed. ioctlsave has been written for this special case. It saves the current terminal settings to a file in the same format as ioctl.save. The procedure is shown in Figure 8-1.

remote.example.edu.au ttyS0 login: root
Password: …
bash# rm -f /etc/ioctl.save
bash# ioctlsave -t /dev/ttyS0 /etc/ioctl.save

8.3. Test the console

Dial in from a machine, perhaps using Minicom.

localhost bash$ minicom

Initializing modem
Welcome to minicom 1.83.1
Press ALT-Z for help on special keys
AT S7=45 S0=0 L1 V1 X4 &C1 E1 Q0                     
OK
Alt-D remote.example.edu.au-ttyS0
Dialing: remote.example.edu.au-ttyS0 At: 1234-5678
Connected. Press any key to continue
Any
CONNECT 115200/V34/LAPM/V42BIS/33600:TX/33600:RX

Enter
/etc/issue says "All your base are belong to us".
remote.example.edu.au ttyS0 login: user
Password: ********
Message of the day is "be careful out there".
remote bash$ stty -a
speed 9600 baud; rows 0; columns 0; 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 tab3 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke
…
remote bash$ logout

NO CARRIER
Alt-X
Leave Minicom? Yes
Resetting modem

localhost bash$

Interestingly the stty -a command, used to display the terminal settings, reports that the link from the modem to the serial console is 9600bps. The CONNECT message reports that link between the two modems operates at 33600bps. The constant speed modem-computer link is a very useful feature of the Hayes AT-style modems: the calling computer need not know in advance the line speed of the called serial console.

8.4. Where to next from here?

The serial console is now configured. Check the security pointers given in Chapter 9 to complete the job.

9.1. Use good passwords

Anyone that can guess the BIOS password, the boot loader password, or the root password can get full control of the machine. These should be different, unrelated, excellent passwords. Random text and digits are by far the best choice. You should never use a password that you think would return a hit from a search engine.[8]

Guessing a user's password is only slightly less severe, as a hacker can obtain root access simply by waiting. The hacker waits for a "local exploit" for a flaw in the operating system to appear and uses that exploit before the machine is patched.

Severely limit the number of users on the machine. Ensure that only good passwords are chosen by using a fascist password checker such as a cracklib-based PAM module.

You should write down the BIOS password, the boot loader password and the root password. Now you don't need to remember them, so there is no reason for them not to be totally random, unrelated, excellent passwords. Fold the page, put it in an envelope and seal it.

Now we have turned a computer security problem into a physical security problem. We know how to solve those problems: locks, keys, alarms, safes, guards, regular inspections. If your site has staffed security then a good option is to leave the envelope in the care of the guard post with instructions to treat the envelope with the same procedures used for the site's master keys. Smaller sites can use a safe, a cash box or a locked drawer. A thief forcing a locked drawer still leaves shows more apparent signs of entry and more clues to their identity than is left by a hacker behind a modem.

These three passwords are an important corporate asset. If the machine is secure then forgetting the major passwords for the machine should result in a machine whose configuration cannot be altered by actions short of disassembly. You should have written procedures controlling the generation, storage, lifetime and use of major passwords.

9.2. Obey Data Terminal Ready and Data Carrier Detect

The RS-232 Data Terminal Ready signal is lowered when the computer wishes the modem to hang up. The computer wishes to hang up when people have ended their login session ends or when they fail to respond to the login: prompt.

Using a modem cable that has DTR wired and a modem that is configured to obey DTR is essential to prevent denial of service attacks upon the access to the console.

Without DTR a caller can simply hold the modem line open, denying system administrators access to the console.

The RS-232 Data Carrier Detect signal is lowered when the user hangs up.

Using a modem cable that has DCD wired and a modem that is configured to assert DCD is essential to prevent people dialling in after a user has hang up and from carrying on their session.

Without DCD the session is not cleared when an accidental disconnection occurs. This allows any subsequent caller to resume the previous session. The machine is totally compromised if the previous user was root.

9.3. Use or configure a dumb modem

Most modems use the Hayes AT command set. The modem's attention is gained by sending +++ surrounded by some idle time. Commands are then sent prefixed by AT.

Unfortunately, if the modem sees +++ during a call it may revert to command mode. The modem can then be configured by the caller. For example, the modem could be set to permit incoming calls only from the number "0", this would deny the system administrators access to the modem.

The attention command can be removed using AT S2=255. Of course once that is done no more AT commands can be given to the modem, so any other configuration of the modem needs to be done prior to that command.

Unfortunately, when power to the modem is applied the modem starts in command mode. So a carefully chosen console message could disable the modem.

The best solution is to select a modem that has a "dumb" or "select profile" DIP switch or jumper. These switches disable command mode and load the modem's saved configuration when they start.

9.4. Restrict console messages

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none  @loghost.example.edu.au
*.info;mail.none;authpriv.none;cron.none  -/var/log/messages

# The authpriv file has restricted access.
authpriv.*                                @loghost.example.edu.au
authpriv.*                                /var/log/secure

# Log all the mail messages in one place.
mail.*                                    @loghost.example.edu.au
mail.*                                    -/var/log/maillog

# Log cron stuff
cron.*                                    @loghost.example.edu.au
cron.*                                    -/var/log/cron

# Everybody gets emergency messages
*.emerg                                   @loghost.example.edu.au
*.emerg                                   *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                            @loghost.example.edu.au
uucp,news.crit                            -/var/log/spooler

# Save boot messages also to boot.log
local7.*                                  @loghost.example.edu.au
local7.*                                  -/var/log/boot.log

# Red Hat Linux default value, does not write timer mark messages
SYSLOGD_OPTIONS="-m 0"
# Add option to accept remote syslog messages
SYSLOGD_OPTIONS="${SYSLOGD_OPTIONS} -r"

 bash# chkconfig iptables on
 bash# /etc/init.d/iptables restart
# Allow all IP traffic from this machine
 bash# iptables --append INPUT --source 127.0.0.0/8 --in-interface lo --jump ACCEPT
# Perhaps filter other traffic
…
# Accept syslog messages from remote.example.edu.au
 bash# iptables --append INPUT --source remote.example.edu.au --protocol udp --destination-port syslog -j ACCEPT
# Silently drop unexpected syslog messages
 bash# iptables --append INPUT --protocol udp --destination-port syslog -j DROP
# Save the running configuration
 bash# /etc/init.d/iptables save

bash# chkconfig nscd on
bash# /etc/init.d/nscd restart

#
# Do we have files referred to?
if [ -x /usr/bin/mesg -a -x /usr/bin/tty ]
then
  # Are we on serial console?
  if [ `/usr/bin/tty` = /dev/ttyS0 ]
  then
    # Do not accept broadcast messages
    /usr/bin/mesg n
  fi
fi

#
# /etc/profile.d/mesg.sh -- prevent people hassling the serial console user
[ -x /usr/bin/mesg -a -x /usr/bin/tty -a `/usr/bin/tty` = /dev/ttyS0 ] && /usr/bin/mesg n

#
# /etc/profile.d/mesg.csh -- prevent people hassling the serial console user
if (-X mesg && -X tty && `tty` == /dev/ttyS0) then
  mesg n
endif

bash# cp mesg.*sh /etc/profile.d/
bash# chown root:root /etc/profile.d/mesg.*sh
bash# chmod u=rwx,g=rx,o=rx /etc/profile.d/mesg.*sh

9.5. Modem features to restrict usage

Most modems support the addition of a password. This is not particularly useful as it has the same strengths and weaknesses of all other password authentication schemes. We already have password authentication in the BIOS, in the boot loader and in login.

Many modems support call-back. The modem is called and a few seconds after hang-up it calls a pre-configured number. This limits the locations that can gain access to the console.

Many modems support checking the calling line identification (CLI) against a predefined list. If the calling number is not on the list then the call is cleared. The phone line to the modem must be configured to send CLI, this may incur an additional charge from the phone company. Not all calling phones can send CLI and some valid callers may have asked their phone company to suppress the sending of CLI.

Many modems can be configured to log the calling line identification. This is useful when tracing misuse.

Many modems support encryption. Some modems allow multiple keys. This gives a neat solution: only authorized modems can dial in, but they can do so from any location. The modems usually need to be of the same make, and perhaps of the same model.

	Encryption dual-use technology
	Possessing, using, buying, selling, importing or exporting modems with encryption features is a serious criminal offense in some countries. You must acquiant yourself with the laws in your jurisdiction and the laws of jurisdictions you may travel through.

Many telephone services or PBX lines can be set to allow only incoming calls. This is useful as it prevents misuse of the modem should the computer be compromised. A "demon dialler" can call many numbers seeking an answering modem and the cost of these calls can be significant.

9.6. BIOS features

Most BIOSs can be configured with a "configuration password". This should set and tested. Some motherboards will require a jumper to be set to allow the password to take effect. Some BIOSs have well-known "master passwords", use a search engine to ensure that your BIOS is not one of these. The password should not be the same as the boot loader or root passwords.

The BIOS configuration will have a "boot order" setting. It should be set to boot from the hard disk before any other media. This prevents someone inserting a rescue diskette, booting the machine, and gaining access to the filesystems as root.

9.7. Use a boot loader password

Configure the boot loader to request a password when booting a non-default image or when supplying parameters from the command line.

This prevents someone from dialing in during the boot sequence and booting the kernel with options to take control of the machine, as in Example 4-1.

The password should not be the same as the BIOS or root passwords.

9.8. Non-interactive boot sequence

Red Hat Linux has an "interactive boot" option that can be used to prevent services from being started. This may not be pleasant if the purpose of the machine is web serving and the HTTP daemon is interactively prevented from starting by an unauthenticated person.

Edit /etc/sysconfig/init to contain the line

PROMPT=no

9.9. Magic SysRq key

The "magic SysRq key" is a key sequence that allows some basic commands to be passed directly to the kernel. Kernel software developers use this interface to debug their software. Under most circumstances it can also be used to uncleanly reboot the computer, something that is otherwise difficult or expensive to do remotely.

For computers that are not used for kernel software development the magic SysRq key makes an ideal denial of service device. A few unauthenticated keystrokes and the computer is dead in the water. The console, serial or otherwise, must be in an area with access limited to trusted people.

The serial console uses the RS-232 break function as the "magic SysRq key". A "break" is a period of no transmission on the serial line, on traditional terminals it is activated by pressing a key labeled Break.

Anyone can dial into a modem and send a break, so if the serial console is attached to a modem we need to disable the magic SysRq key . If the serial console is attached to a terminal server which asks for authentication, or is attached directly to another terminal using a null modem cable then you may decide to activate the magic SysRq key.

The magic SysRq key can be disabled by setting a kernel variable or by not compiling support for the key.

Writing a 0 into /proc/sys/kernel/sysrq will disable the magic SysRq key. The command sysctl can also be used:

bash# sysctl -w kernel.sysrq=0

Your Linux distribution may have a file /etc/sysctl.conf which is used to run sysctl during the boot of the machine. Add the lines:

# Disables the magic SysRq key
kernel.sysrq = 0

Even when setting the magic SysRq key off in /etc/sysctl.conf there is a period of vulnerability after the kernel boots but before contents of the file are applied.

It is much better to compile your own kernel and set the following configuration parameter:

Kernel hacking  --->
 [ ] Magic SysRq key

This should place the following configuration parameter in /usr/src/linux/.config.

# CONFIG_MAGIC_SYSRQ is not set

9.10. Adjust behaviour of Ctrl-Alt-Delete

The IBM PC used Ctrl-Alt-Delete to launch a reboot of the computer. Linux traps this key chord and makes it available to the init system. This is done by sending the init process a SIGINT signal (although ctrlaltdel hard can undo this trap and make the key chord reboot the comptuer immediately). The init system uses /etc/inittab to determine how to handle the signal generated by the Ctrl-Alt-Delete key chord.

Most distributions cleanly reboot the system, mimicing the behaviour that most users expect. Figure 9-14 shows how this is done.

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Depending upon each individual site you may wish to disable Ctrl-Alt-Delete. This is shown in Figure 9-15.

# Trap CTRL-ALT-DELETE and do nothing
ca::ctrlaltdel:

Alternatively, you may wish to cleanly shut down the computer. This is very easy to explain to operators and instructions can be displayed on the monitor using /etc/issue or a Post-it Note. If the computer uses Advanced Power Management (or APM) then shutting down the computer will also remove the power.

# Trap CTRL-ALT-DELETE and shut down
ca::ctrlaltdel:/sbin/shutdown -t3 -h now

9.11. Log attempted access

Look in the system logs for the output of getty. Add the monitoring of these messages to your log-watching procedures.

9.12. Countering interception of telephony links

Modems calls over telephones can be intercepted. This can be an issue if you do not trust a telecommunications carrier in your call's path, or if you do not trust the law enforcement agencies that may request interception facilities from that carrier.

International calls are particularly exposed. Calls which are routed across satellite or wireless links can be intercepted by readily-available radio receivers. Calls routed across undersea links are much more expensive to intercept, so this is probably limited to national governments, such as those using the Echelon system.

If you do not pass sensitive data over the link, then the major exposure is typing in your user name and password. Look into S/KEY or look into OPIE and its related An OPIE for PAM.

These one-time password systems have flaws, a good summary of these is Vulnerabilities in the S/KEY one time password system by Peiter ‘mudge’ Zatko.

	Cryptographic key material
	Possessing cryptographic key material, such as a one-time password generator or list of one-time passwords, is a serious criminal offense in some countries. You must acquiant yourself with the laws in your jurisdiction and the laws of jurisdictions you may travel through.

	Defeating telecommunications interception
	Taking steps to defeat or avoid legislatively-approved telecommunications interception is a serious criminal offense in some countries. You must acquiant yourself with the laws in your jurisdiction and the laws of jurisdictions you may travel through.

10.1. Linux kernel version 2.5

Kernel version 2.5 is under active development, so this section may be out of date. Version 2.5 includes support for the console to a serial port attached to a USB dongle. The -dj patch to the version 2.5 kernel has a rewritten console layer; it is not known if the rewritten layer effects the user-space use of the serial console.

When configuring the kernel set the following configuration parameters:

Character devices  --->
 [*] Virtual terminal
  [*]   Support for console on virtual terminal
 <*> Standard/generic (8250/16550 and compatible UARTs) serial support
  [*]   Support for console on serial port

This should set the following configuration parameters in /usr/src/linux/.config.

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y

If you also want to use a serial port attached to a USB bus, then in addition to the usual USB configuration, configure the kernel to load the USB console driver and one of the USB serial dongles (our example uses the generic serial dongle).

USB Serial Converter support --->
 <M> USB Serial Converter support
 [M] USB Serial Console device support
 [M] USB Generic Serial Driver

This should set the following configuration parameters in /usr/src/linux/.config

CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_CONSOLE=m
CONFIG_USB_SERIAL_GENERIC=m

You should also configure the kernel without the magic SysRq key, as described in Section 9.9.

10.2. Linux kernel version 2.4

When configuring the kernel set the following configuration parameters:

Character devices  --->
 [*] Virtual terminal
  [*]   Support for console on virtual terminal
 <*> Standard/generic (8250/16550 and compatible UARTs) serial support
  [*]   Support for console on serial port

This should set the following configuration parameters in /usr/src/linux/.config.

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y

You should also configure the kernel without the magic SysRq key, as described in Section 9.9.

10.3. Linux kernel version 2.2

The later Linux 2.2 kernels use the same build parameters and parameter syntax as the Linux version 2.4 kernels.

For earlier kernels see the article by Francesco Conti in issue 36 of Linux Journal published in April 1997.

This article included some patches for the kernel, which have been extended in the notes below to use a broader range of serial port speeds.

Choose to use the serial console by adding a couple of #defines at the start of /usr/src/linux/drivers/char/console.c:

#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x3f8  /* COM1 port address */

Alternatively, to use ttyS1 use these lines:

#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x2f8  /* COM2 port address */

The kernel assumes a serial link speed of 9600bps. If you are using a differing bit rate then find these two lines:

serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
serial_echo_outb(0x0c, UART_DLL);

and change 0x0c to one of the values in Table 10-1.

11.1. Jargon

RS-232 cables were originally intended to link terminals to modems. The terminal is formally named a Data Terminal Equipment, abbreviated to DTE. The modem is formally named a Data Communications Equipment, abbreviated to DCE.

A standard RS-232 cable has a 25-pin D-type socket, which connects to the DTE, and a 25-pin D-type plug, which connects to the DCE. All 25 pins are connected, with pin 1 on the plug wired to pin 1 on the socket, pin 2 on the plug wired to pin 2 on the socket, and so on. The shielding of the cable is attached to the metallic cover on the socket.

RS-232 signaling is much more robust than the signalling of many other communications standards. Pins can be shorted, not connected or drive more than one output.

Signals are named from the point of view of the Data Terminal Equipment. So Transmit Data on the DTE is connected to Transmit Data on the DCE. The Transmit Data pin on the DTE actually transmits data, whereas Transmit Data pin on the DCE actually recieves data.

11.2. Cable from console port to modem

The RS-232 standard defines the interconnection of computers and modems, so there is little to go wrong here by simply purchasing a pre-assembled cable. There are two types of cable: cables with connectors for a standard 25-pin D connector on the computer; and cables with connectors for a proprietary 9-pin D connector used on the IBM PC/AT and many other computers. The cables have titles like RS-232 25-pin computer (DTE) to 25-pin modem (DCE) or RS-232 9-pin IBM PC/AT computer (DTE) to 25-pin modem (DCE). Most modems are packaged with a suitable cable.

If you need to manufacture your own cables, see the Serial-HOWTO for the RS-232 pinout for your computer. Connect Transmit Data on the computer to Transmit Data on the modem, Receive Data on the computer to Receive Data on the modem, and so on for Signal Ground, Clear to Send, Ready to Send, Data Set Ready, Data Terminal Ready and Data Carrier Detect.

For professional computer room installations consider routing the serial cable through an RJ-45 patch panel. There are two common pinouts on used on the RJ-45 connector: Yost and Cisco 2500-series.

If you create your own pinout for unshielded twisted pair cable then be sure that your pinout twists a Signal Ground wire with the Transmit Data wire and another Signal Ground wire with the Receive Data wire. Although the RS-232 signals are not balanced, this twist will result in the least amount of signal degradation and noise pickup.

11.3. Cable from console port to terminal (or another PC)

The RS-232 standard allows for, but does not specify, the interconnection of two computers without intervening modems. A special cable is required, called a "null modem" cable.

The wiring within the null modem cable depends upon the handshaking and control signals that are needed. Differing manufacturers have differing views on this topic, so don't buy a null modem cable that does not come with a wiring diagram.

Linux needs all of the flow control and modem control signals to be correctly wired. The correct wiring of a null modem cable is shown in Figure 11-1 with an alternative shown in Figure 11-2.

Linux uses CTS and RTS to do handshaking, preventing the computer from overrunning the terminal and preventing the terminal from overrunning the computer. If you are connecting two computers together, then you will not get reliable file transfers without CTS/RTS handshaking.

Linux uses DSR and DCD to sense that a terminal is connected. It will then request a login. If a session is established and DCD falls then Linux will log out the user.

Linux uses DTR to force the link to be cleared. It does this after a user logs off to free up the communications channel.

Either of the null modem designs in Figure 11-1 or Figure 11-2 meets the requirements of the Linux kernel. Figure 11-2 may be marginally better when both computers are remotely located, as the differing states of DSR and DCD can be used to determine which end of the null modem cable has become faulty.

All null modem designs have a common flaw. Computers interconnected with real modems modem will drop Data Set Ready for some time after the local modem is reset by the local computer dropping Data Terminal Ready. Most software is designed to accomodate this slight difference between modem links and null modem links.

Major security exposures and significant loss of reliability can occur with incorrectly wired null modem cables, including the cables in Figure 11-3, Figure 11-4 and Figure 11-5.

      Signal ground ---------------------- Signal ground

       Receive data ---------------------- Transmit data

      Transmit data ---------------------- Receive data

      Ready to send ---------------------- Clear to send

      Clear to send ---------------------- Ready to send

Data terminal ready -----------------+---- Data carrier detect
                                     |
                                     +---- Data set ready

Data carrier detect ----+----------------- Data terminal ready
                        |
     Data set ready ----+

    Ring indication -- not connected

                          not connected -- Ring indication

      Signal ground ---------------------- Signal ground

       Receive data ---------------------- Transmit data

      Transmit data ---------------------- Receive data

      Ready to send ---------------------- Clear to send

      Clear to send ---------------------- Ready to send

Data terminal ready ----+----------------- Data carrier detect
                        |
     Data set ready ----+

                                     +---- Data set ready
                                     |
Data carrier detect ----+------------+---- Data terminal ready

    Ring indication -- not connected

                          not connected -- Ring indication

Unfortunately not all Linux boot loaders support the control signals required by the Linux operating system. This odd state of affairs may force you to do away with control signals and handshaking if you need to issue commands to the boot loader.

There are two ways of defeating the RS-232 handshaking: software and hardware.

If you have a modem then by far the best technique is to disable the control signals and handshaking by using AT commands to configure the modem's software. This allows the handshaking to be restored when the boot loader authors correct their support for serial connections.

For a null modem cable the best approach is to disable handshaking in your terminal emulation software.

In the worst case for a null modem you will need a cable that falsifies the handshaking and control signals. Try not to use these cables in a production environment.

      Signal ground ---------------------- Signal ground

       Receive data ---------------------- Transmit data

      Transmit data ---------------------- Receive data

Data terminal ready ---+              +--- Data terminal ready
                       |              |
      Clear to send ---+              +--- Clear to send
                       |              |
Data carrier detect ---+              +--- Data terminal ready
                       |              |
     Data set ready ---+              +--- Data set ready

      Ready to send -- not connected

                          not connected -- Ready to send

    Ring indication -- not connected

                          not connected -- Ring indication

If you are happy with a quick hack, perhaps just to use a serial console to grab a kernel oops message, then you can configure some getty programs to ignore the RS-232 status signals. For example, mgetty has the direct option in mgetty.conf. In this case only a three-wire or two-wire RS-232 null modem cable is needed.

Signal ground ---------------------- Signal ground

 Receive data ---------------------- Transmit data

Transmit data ---------------------- Receive data

Signal ground ---------------------- Signal ground

Transmit data ---------------------- Receive data

Don't use these cables in a production environment.

11.4. Lengths of serial cables

The RS-232 standard 9600bps port will drive 15 metres of shielded cable. More precisely, an RS-232 line driver will operate against a capacitance of up to 2500 picoFarad with low enough skew to allow a 9600bps signal to be recovered.

If you select a cable with lower capacitance you can drive further distances. For example, ANSI/TIA/EIA-568-A unshielded twisted pair category 5 cable has a maximum capacitiance of 55pF per metre, so this popular "UTP cat 5" cable can be safely driven up to 45m. Beyond that you should check the cable manufacturers specifications for the actual "shunt capacitance" (a common figure is 47.5 pF/m, giving a maximum cable length of about 50m). However long runs of unshielded cable will pick up noise easily, as the RS-232 signals are not balanced. Some cable manufacturers offer shielded low capacitance cables which can be driven up to 100m.

Similarly, if you select a lower data rate you can drive further distances. Table 11-1 shows the maximum distances over standard shielded cable at differing data rates.

If you are comfortable in working beyond specifications then you might note that the experience of enterprise network operators has been that structured cabling layout in buildings is limited by the 100m distance limitation of fast ethernet over category 5 cable, not by the practical distances achieved by RS-232 asynchronous signals at 9600bps over category 5 cable.

For longer distances use an RS-232 line driver; these will typically drive up to 2000 meters over category 3 UTP cable. For greater distances consider using fiber optical modems, the global telephony system, the mobile telephony system, satellite or radio.

11.5. Making serial cables

If you use a serial console for densely-racked computers you will end up making a lot of null-modem serial cables. This section has some hints on making serial cables. If you are making more than ten cables and live in a city you will probably find it economic to have the cables made by a specialty cabling firm.

Attempt to minimise noise in your cabling design. Many BIOSs and boot loaders will wait forever if they receive a single character of line noise. You might choose to use shielded UTP cables (these require special RJ-45 plugs but use standard RJ-45 sockets).

If the environment has a lot of radio frequency noise then use traditional shielded cable and metal RS-232 connector shells. Connect the shield in the cable to the computer at one end. This can be done by connecting the drain wire of the shield it to the Protective Ground (if present) or by soldering the drain wire to the shell of the connector. If there is a substantial amount of noise also place a ferrite core over the shielded cable at both ends of the cable. Follow the usual good practices of making the cable to the correct length and screwing home the D connectors into the chassis.

If you are making one of these cables and have some soldering skill, you can easily do the jumpering of the signal wires within the backshell of the DB9 or DB25 connector.

If you are making a large number of cables then crimping systems are much faster than soldering. Again, pin jumpering can be done within the backshell.

No matter what system is adopted, use the Resistance setting of a multimeter to check for dead and shorted pins. A minute here can save hours later.

For structured cabling systems, space is tight within DB9/RJ-45 backshells, so the jumpering is better done behind the patch panel. The DB9/RJ-45 connectors present the IBM PC pinout at the DB9 connector and present the Yost or Cisco pinout at the RJ-45 connector.

	Incompatible devices in structured cabling systems
	Take care to connect only RS-232 devices to RS-232 devices when patching structured cabling systems. Other cables may be carrying ethernet, ISDN, telephony, alarm and DC power voltages. Connecting incompatible voltages may destroy equipment.

12.1. Using Minicom to give commands to a modem

Minicom is a full-screen serial terminal emulation package, very much like the classic Telix terminal emulator for MS-DOS.

Firstly, start Minicom in configuration mode with the command:

bash# minicom -o -s

The following menu appears:

Filenames and paths
File transfer protocols
Serial port setup
Modem and dialing
Screen and keyboard
Save setup as dfl
Save setup as..
Exit
Exit from Minicom

Select Serial port setup and set

A - Serial Device: /dev/ttyS0
B - Lockfile Location: /var/lock
C - Callin Program:
D - Callout Program:
E - Bps/Par/Bits: 9600 8N1
F - Hardware Flow Control: Yes
G - Software Flow Control: No

Now save the configuration

Give name to save this configuration?
> console

and exit Minicom.

To configure a modem use the command minicom -o console to start Minicom without sending an initialization string to the modem. Now issue the AT commands to configure the modem.

When finished use the Quit option to leave Minicom without sending a reset string to the modem; this option is Alt-Q.

Sometimes Minicom will use Ctrl-A rather than Alt to access the menu system, look for a hint in Minicom's start up message:

Press ALT-Z for help on special keys

Press CTRL-A Z for help on special keys

12.2. Configure dumb modem

Linux, like most UNIX-like operating systems, expects a serial console to be connected to a dumb modem. Dumb modems are not seen much these days, perhaps only on exotic hardware such as ISDN terminal adapters or satellite ground terminals.

A dumb modem is configured using hardware. Figure 12-1 shows the front panel of a fanciful dumb modem. In reality the speed and mode settings are likely to be done using jumpers or DIP switches.

+-----------------------------+
|                             |
|    SPEED       MODE         |
|  [ ]  300    [ ] Originate  |
|  [ ]  600    [X] Answer     |
|  [ ] 2400                   |
|  [X] 9600                   |
|                             |
+-----------------------------+

The modem's speed is set to the desired bit rate, in our case 9600bps. The modem's mode is set to Answer, that is, to wait for incoming calls and to answer them.

If the RS-232 control line Data Terminal Ready is low, the modem will not answer a call. The computer is off or the computer's serial interface is not yet initialized. Once DTR is high the modem will answer incoming calls.

Once an incoming call is established the modem raises the Data Carrier Detect control line. Only when DCD is high is received data valid (data receieved from a dumb modem when DCD is not asserted is probably line noise). Only when DCD is high is transmitted data passed through the link.

getty on the Linux computer has been waiting for DCD to come high, and getty welcomes the user and requests them to log in.

Whilst the user is logged in and data is flowing, Clear to Send and Ready to Send are used between the modem and the computer to prevent data being sent too soon. The computer lowers Ready to Send when it is too busy to receive a character. The modem lowers Clear to Send when it is too busy to receive a character.

When the user hangs up, Data Carrier Detect falls and the hang up signal is sent to all processes associated with the dial in session.

Alternatively, the user can log out. When the shell dies, the computer pulls Data Terminal Ready low, causing the modem to hang up. When the getty brings Data Terminal Ready high again, the modem will accept more incoming calls.

We have not yet described Data Set Ready. This line is low if the modem is off or if the modem has not yet initialized. When DSR is low all other signals from the modem are undefined. For example, if DSR is low but DCD "floats" to the high voltage then software should behave as if DCD is not asserted.

12.3. Configure modem with AT commands

Most modems today are smart modems based upon the Hayes modems and their command sets. But as discussed above, the Linux serial console is designed to operate with a dumb modem.

Thus the smart modem is dumbed-down until it resembles a dumb modem. Some expensive modems will have a DIP switch or board jumper to put them into dumb mode.

It is essential to have a manual for the modem which describes that modem's AT commands. Although most modems agree on the more popular AT commands, they differ in the more technical commands.

bash# minicom -o console
Welcome to minicom
Press CTRL-A Z for help on special keys

Enter Enter Enter

ATI Enter
56k V.90 Series 3 External V2.20

Ctrl-A Q
Leave without reset? Yes

CONNECT 9600

bash# minicom -o console
Welcome to minicom
Press CTRL-A Z for help on special keys

AT &F Enter
OK

AT Z Enter
OK

AT &C1 &D2 &K3 S0=2 M0 Enter
OK

AT E0 Q1 S2=255 &W Enter

Alt-A Q
Leave without reset? Yes

bash# minicom -o console
Welcome to minicom
Press CTRL-A Z for help on special keys

AT &F &Y0 &W &W1 Enter
OK
AT Z Enter
OK

Alt-A Q
Leave without reset? Yes

12.4. Internal modems

An internal modem is basically an external modem and serial port mounted upon a PC bus card. These are cheaper than external modems as they do not require a power supply or a chassis.

Internal modems work fine for remote serial console applications. They are especially attractive for computers at co-location sites, as those sites charge according to space and power consumption.

Check that your internal modem preserves its setting across a power cycle.

Ensure that the interrupt line and port address space used by the internal modem's serial port do not conflict with that used by any other pre-existing serial ports. Alternatively, ensure that the internal serial port can be disabled, freeing its interrupt line and port address space for use by the internal modem.

Be careful not to confuse an internal modem with a WinModem. An internal modem does not need a special device driver, but appears to Linux as a stardard serial port.

12.5. WinModems

If you look at a modem, with it's small central processing unit and special-purpose digital signal processor, and then look at a modern PC, with it's large CPU and general-purpose DSP on the sound card, you may wonder if the hardware duplication of an external modem is necessary.

A "WinModem" incorporates the CPU and DSP of the modem into the slightly-enhanced fabric of a PC. They are called "WinModems" because they originally only shipped with Microsoft Windows device drivers. These device drivers presented the illusion of a serial port attached to a Hayes AT-style modem. For a long time only Windows versions of these drivers where available. Some manufacturers now provide Linux versions of their device drivers as well, these modems are jokingly called "LinModems".

It is probably possible to use a LinModem as a Linux console. At the most this would require altering the source code to dumb-down the AT command emulation of the modem and recompiling the kernel.

Boot loaders, however, work in a very confined software environment and struggle to support a simple serial chip. Considering that some boot loaders do not even handle interrupts, handling the complex DSP of a LinModem is well beyond what is practical.