Terminals provide a convenient and low-cost way to access a FreeBSD system when not at the computer's console or on a connected network. This section describes how to use terminals with FreeBSD.
The original UNIX® systems did not have consoles. Instead, users logged in and ran programs through terminals that were connected to the computer's serial ports.
The ability to establish a login session on a serial port
still exists in nearly every UNIX®-like operating system
today, including FreeBSD. By using a terminal attached to an
unused serial port, a user can log in and run any text program
that can normally be run on the console or in an
xterm window.
Many terminals can be attached to a FreeBSD system. An older spare computer can be used as a terminal wired into a more powerful computer running FreeBSD. This can turn what might otherwise be a single-user computer into a powerful multiple-user system.
FreeBSD supports three types of terminals:
- Dumb terminals
Dumb terminals are specialized hardware that connect to computers over serial lines. They are called “dumb” because they have only enough computational power to display, send, and receive text. No programs can be run on these devices. Instead, dumb terminals connect to a computer that runs the needed programs.
There are hundreds of kinds of dumb terminals made by many manufacturers, and just about any kind will work with FreeBSD. Some high-end terminals can even display graphics, but only certain software packages can take advantage of these advanced features.
Dumb terminals are popular in work environments where workers do not need access to graphical applications.
- Computers Acting as Terminals
Since a dumb terminal has just enough ability to display, send, and receive text, any spare computer can be a dumb terminal. All that is needed is the proper cable and some terminal emulation software to run on the computer.
This configuration can be useful. For example, if one user is busy working at the FreeBSD system's console, another user can do some text-only work at the same time from a less powerful personal computer hooked up as a terminal to the FreeBSD system.
There are at least two utilities in the base-system of FreeBSD that can be used to work through a serial connection: cu(1) and tip(1).
For example, to connect from a client system that runs FreeBSD to the serial connection of another system:
#cu -lserial-port-deviceReplace
serial-port-devicewith the device name of the connected serial port. These device files are called/dev/cuauon FreeBSD versions 10.x and higher andN/dev/cuadon FreeBSD versions 9.x and lower. In either case,NNis the serial port number, starting from zero. This means thatCOM1is/dev/cuau0or/dev/cuad0in FreeBSD.Additional programs are available through the Ports Collection, such as comms/minicom.
- X Terminals
X terminals are the most sophisticated kind of terminal available. Instead of connecting to a serial port, they usually connect to a network like Ethernet. Instead of being relegated to text-only applications, they can display any Xorg application.
This chapter does not cover the setup, configuration, or use of X terminals.
This section describes how to configure a FreeBSD system to enable a login session on a serial terminal. It assumes that the system recognizes the serial port to which the terminal is connected and that the terminal is connected with the correct cable.
In FreeBSD, init reads
/etc/ttys and starts a
getty process on the available terminals.
The getty process is responsible for
reading a login name and starting the login
program. The ports on the FreeBSD system which allow logins are
listed in /etc/ttys. For example, the
first virtual console, ttyv0, has an
entry in this file, allowing logins on the console. This file
also contains entries for the other virtual consoles, serial
ports, and pseudo-ttys. For a hardwired terminal, the serial
port's /dev entry is listed without the
/dev part. For example,
/dev/ttyv0 is listed as
ttyv0.
The default /etc/ttys configures
support for the first four serial ports,
ttyu0 through
ttyu3:
ttyu0 "/usr/libexec/getty std.9600" dialup off secure ttyu1 "/usr/libexec/getty std.9600" dialup off secure ttyu2 "/usr/libexec/getty std.9600" dialup off secure ttyu3 "/usr/libexec/getty std.9600" dialup off secure
When attaching a terminal to one of those ports, modify
the default entry to set the required speed and terminal type,
to turn the device on and, if needed, to
change the port's secure setting. If the
terminal is connected to another port, add an entry for the
port.
Example 26.1, “Configuring Terminal Entries” configures two terminals in
/etc/ttys. The first entry configures a
Wyse-50 connected to COM2. The second
entry configures an old computer running
Procomm terminal software emulating
a VT-100 terminal. The computer is connected to the sixth
serial port on a multi-port serial card.
ttyu1ttyu5 "/usr/libexec/getty std.19200" vt100 on insecure
| The first field specifies the device name of the serial terminal. |
| The second field tells When setting the getty type, make sure to match the communications settings used by the terminal. For this example, the Wyse-50 uses no parity and connects at 38400 bps. The computer uses no parity and connects at 19200 bps. |
| The third field is the type of terminal. For
dial-up ports, |
| The fourth field specifies if the port should be
enabled. To enable logins on this port, this field must
be set to |
| The final field is used to specify whether the port
is secure. Marking a port as |
After making any changes to
/etc/ttys, send a SIGHUP (hangup) signal
to the init process to force it to re-read
its configuration file:
#kill -HUP 1
Since init is always the first process
run on a system, it always has a process ID
of 1.
If everything is set up correctly, all cables are in
place, and the terminals are powered up, a
getty process should now be running on each
terminal and login prompts should be available on each
terminal.
Even with the most meticulous attention to detail, something could still go wrong while setting up a terminal. Here is a list of common symptoms and some suggested fixes.
If no login prompt appears, make sure the terminal is plugged in and powered up. If it is a personal computer acting as a terminal, make sure it is running terminal emulation software on the correct serial port.
Make sure the cable is connected firmly to both the terminal and the FreeBSD computer. Make sure it is the right kind of cable.
Make sure the terminal and FreeBSD agree on the bps rate and parity settings. For a video display terminal, make sure the contrast and brightness controls are turned up. If it is a printing terminal, make sure paper and ink are in good supply.
Use ps to make sure that a
getty process is running and serving the
terminal. For example, the following listing shows that a
getty is running on the second serial port,
ttyu1, and is using the
std.38400 entry in
/etc/gettytab:
#ps -axww|grep ttyu22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyu1
If no getty process is running, make
sure the port is enabled in /etc/ttys.
Remember to run kill -HUP 1 after modifying
/etc/ttys.
If the getty process is running but the
terminal still does not display a login prompt, or if it
displays a prompt but will not accept typed input, the
terminal or cable may not support hardware handshaking. Try
changing the entry in /etc/ttys from
std.38400 to
3wire.38400, then run kill -HUP
1 after modifying /etc/ttys.
The 3wire entry is similar to
std, but ignores hardware handshaking. The
baud rate may need to be reduced or software flow control
enabled when using 3wire to prevent buffer
overflows.
If garbage appears instead of a login prompt, make sure
the terminal and FreeBSD agree on the bps rate
and parity settings. Check the getty
processes to make sure the correct
getty type is in use. If not, edit
/etc/ttys and run kill
-HUP 1.
If characters appear doubled and the password appears when typed, switch the terminal, or the terminal emulation software, from “half duplex” or “local echo” to “full duplex.”