2200 lines
77 KiB
XML
2200 lines
77 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD$
|
|
-->
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
|
xml:id="serialcomms">
|
|
<title>Serial Communications</title>
|
|
|
|
<sect1 xml:id="serial-synopsis">
|
|
<title>Synopsis</title>
|
|
|
|
<indexterm><primary>serial communications</primary></indexterm>
|
|
|
|
<para>&unix; has always had support for serial communications as
|
|
the very first &unix; machines relied on serial lines for user
|
|
input and output. Things have changed a lot from the days
|
|
when the average terminal consisted of a 10-character-per-second
|
|
serial printer and a keyboard. This chapter covers some of the
|
|
ways serial communications can be used on &os;.</para>
|
|
|
|
<para>After reading this chapter, you will know:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>How to connect terminals to a &os; system.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>How to use a modem to dial out to remote hosts.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>How to allow remote users to login to a &os; system
|
|
with a modem.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>How to boot a &os; system from a serial console.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Before reading this chapter, you should:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Know how to <link linkend="kernelconfig"> configure and
|
|
install a custom kernel</link>.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Understand <link linkend="basics"> &os; permissions
|
|
and processes</link>.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Have access to the technical manual for the serial
|
|
hardware to be used with &os;.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="serial">
|
|
<title>Serial Terminology and Hardware</title>
|
|
|
|
<para>The following terms are often used in serial
|
|
communications:</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><acronym>bps</acronym></term>
|
|
<listitem>
|
|
<para>Bits per
|
|
Second<indexterm><primary>bits-per-second</primary></indexterm>
|
|
(<acronym>bps</acronym>) is the rate at which data is
|
|
transmitted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><acronym>DTE</acronym></term>
|
|
<listitem>
|
|
<para>Data Terminal
|
|
Equipment<indexterm><primary>DTE</primary></indexterm>
|
|
(<acronym>DTE</acronym>) is one of two endpoints in a
|
|
serial communication. An example would be a
|
|
computer.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><acronym>DCE</acronym></term>
|
|
<listitem>
|
|
<para>Data Communications
|
|
Equipment<indexterm><primary>DCE</primary></indexterm>
|
|
(<acronym>DTE</acronym>) is the other endpoint in a
|
|
serial communication. Typically, it is a modem or serial
|
|
terminal.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><acronym>RS-232</acronym></term>
|
|
<listitem>
|
|
<para>The original standard which defined hardware serial
|
|
communications. It has since been renamed to
|
|
<acronym>TIA-232</acronym>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>When referring to communication data rates, this section
|
|
does not use the term <firstterm>baud</firstterm>. Baud refers
|
|
to the number of electrical state transitions made in a period
|
|
of time, while <acronym>bps</acronym> is the correct term to
|
|
use.</para>
|
|
|
|
<para>To connect a serial terminal to a &os; system, a serial port
|
|
on the computer and the proper cable to connect to the serial
|
|
device are needed. Users who are already familiar with serial
|
|
hardware and cabling can safely skip this section.</para>
|
|
|
|
<sect2 xml:id="term-cables-null">
|
|
<title>Serial Cables and Ports</title>
|
|
|
|
<para>There are several different kinds of serial cables. The
|
|
two most common types are null-modem cables and standard
|
|
<acronym>RS-232</acronym> cables. The documentation for the
|
|
hardware should describe the type of cable required.</para>
|
|
|
|
<para>These two types of cables differ in how the wires are
|
|
connected to the connector. Each wire represents a signal,
|
|
with the defined signals summarized in <xref
|
|
linkend="serialcomms-signal-names"/>. A standard serial
|
|
cable passes all of the <acronym>RS-232C</acronym> signals
|
|
straight through. For example, the <quote>Transmitted
|
|
Data</quote> pin on one end of the cable goes to the
|
|
<quote>Transmitted Data</quote> pin on the other end. This is
|
|
the type of cable used to connect a modem to the &os; system,
|
|
and is also appropriate for some terminals.</para>
|
|
|
|
<para>A null-modem cable switches the <quote>Transmitted
|
|
Data</quote> pin of the connector on one end with the
|
|
<quote>Received Data</quote> pin on the other end. The
|
|
connector can be either a <acronym>DB-25</acronym> or a
|
|
<acronym>DB-9</acronym>.</para>
|
|
|
|
<para>A null-modem cable can be constructed using the pin
|
|
connections summarized in <xref linkend="nullmodem-db25"/>,
|
|
<xref linkend="nullmodem-db9"/>, and <xref
|
|
linkend="nullmodem-db9-25"/>. While the standard calls for
|
|
a straight-through pin 1 to pin 1 <quote>Protective
|
|
Ground</quote> line, it is often omitted. Some terminals
|
|
work using only pins 2, 3, and 7, while others require
|
|
different configurations. When in doubt, refer to the
|
|
documentation for the hardware.</para>
|
|
|
|
<indexterm>
|
|
<primary>null-modem cable</primary>
|
|
</indexterm>
|
|
|
|
<table frame="none" pgwide="1"
|
|
xml:id="serialcomms-signal-names">
|
|
<title><acronym>RS-232C</acronym> Signal Names</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Acronyms</entry>
|
|
<entry align="left">Names</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><acronym>RD</acronym></entry>
|
|
<entry>Received Data</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>TD</acronym></entry>
|
|
<entry>Transmitted Data</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>DTR</acronym></entry>
|
|
<entry>Data Terminal Ready</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>DSR</acronym></entry>
|
|
<entry>Data Set Ready</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>DCD</acronym></entry>
|
|
<entry>Data Carrier Detect</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>SG</acronym></entry>
|
|
<entry>Signal Ground</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>RTS</acronym></entry>
|
|
<entry>Request to Send</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><acronym>CTS</acronym></entry>
|
|
<entry>Clear to Send</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none" pgwide="1" xml:id="nullmodem-db25">
|
|
<title>DB-25 to DB-25 Null-Modem Cable</title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Signal</entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry></entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry align="left">Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>SG</entry>
|
|
<entry>7</entry>
|
|
<entry>connects to</entry>
|
|
<entry>7</entry>
|
|
<entry>SG</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>TD</entry>
|
|
<entry>2</entry>
|
|
<entry>connects to</entry>
|
|
<entry>3</entry>
|
|
<entry>RD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>RD</entry>
|
|
<entry>3</entry>
|
|
<entry>connects to</entry>
|
|
<entry>2</entry>
|
|
<entry>TD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>RTS</entry>
|
|
<entry>4</entry>
|
|
<entry>connects to</entry>
|
|
<entry>5</entry>
|
|
<entry>CTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>CTS</entry>
|
|
<entry>5</entry>
|
|
<entry>connects to</entry>
|
|
<entry>4</entry>
|
|
<entry>RTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>20</entry>
|
|
<entry>connects to</entry>
|
|
<entry>6</entry>
|
|
<entry>DSR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>20</entry>
|
|
<entry>connects to</entry>
|
|
<entry>8</entry>
|
|
<entry>DCD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DSR</entry>
|
|
<entry>6</entry>
|
|
<entry>connects to</entry>
|
|
<entry>20</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DCD</entry>
|
|
<entry>8</entry>
|
|
<entry>connects to</entry>
|
|
<entry>20</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none" pgwide="1" xml:id="nullmodem-db9">
|
|
<title>DB-9 to DB-9 Null-Modem Cable</title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Signal</entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry></entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry align="left">Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>RD</entry>
|
|
<entry>2</entry>
|
|
<entry>connects to</entry>
|
|
<entry>3</entry>
|
|
<entry>TD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>TD</entry>
|
|
<entry>3</entry>
|
|
<entry>connects to</entry>
|
|
<entry>2</entry>
|
|
<entry>RD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>4</entry>
|
|
<entry>connects to</entry>
|
|
<entry>6</entry>
|
|
<entry>DSR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>4</entry>
|
|
<entry>connects to</entry>
|
|
<entry>1</entry>
|
|
<entry>DCD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>SG</entry>
|
|
<entry>5</entry>
|
|
<entry>connects to</entry>
|
|
<entry>5</entry>
|
|
<entry>SG</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DSR</entry>
|
|
<entry>6</entry>
|
|
<entry>connects to</entry>
|
|
<entry>4</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DCD</entry>
|
|
<entry>1</entry>
|
|
<entry>connects to</entry>
|
|
<entry>4</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>RTS</entry>
|
|
<entry>7</entry>
|
|
<entry>connects to</entry>
|
|
<entry>8</entry>
|
|
<entry>CTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>CTS</entry>
|
|
<entry>8</entry>
|
|
<entry>connects to</entry>
|
|
<entry>7</entry>
|
|
<entry>RTS</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none" pgwide="1" xml:id="nullmodem-db9-25">
|
|
<title>DB-9 to DB-25 Null-Modem Cable</title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Signal</entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry></entry>
|
|
<entry align="left">Pin #</entry>
|
|
<entry align="left">Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>RD</entry>
|
|
<entry>2</entry>
|
|
<entry>connects to</entry>
|
|
<entry>2</entry>
|
|
<entry>TD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>TD</entry>
|
|
<entry>3</entry>
|
|
<entry>connects to</entry>
|
|
<entry>3</entry>
|
|
<entry>RD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>4</entry>
|
|
<entry>connects to</entry>
|
|
<entry>6</entry>
|
|
<entry>DSR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DTR</entry>
|
|
<entry>4</entry>
|
|
<entry>connects to</entry>
|
|
<entry>8</entry>
|
|
<entry>DCD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>SG</entry>
|
|
<entry>5</entry>
|
|
<entry>connects to</entry>
|
|
<entry>7</entry>
|
|
<entry>SG</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DSR</entry>
|
|
<entry>6</entry>
|
|
<entry>connects to</entry>
|
|
<entry>20</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>DCD</entry>
|
|
<entry>1</entry>
|
|
<entry>connects to</entry>
|
|
<entry>20</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>RTS</entry>
|
|
<entry>7</entry>
|
|
<entry>connects to</entry>
|
|
<entry>5</entry>
|
|
<entry>CTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>CTS</entry>
|
|
<entry>8</entry>
|
|
<entry>connects to</entry>
|
|
<entry>4</entry>
|
|
<entry>RTS</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<note>
|
|
<para>When one pin at one end connects to a pair of pins at
|
|
the other end, it is usually implemented with one short wire
|
|
between the pair of pins in their connector and a long wire
|
|
to the other single pin.</para>
|
|
</note>
|
|
|
|
<para>Serial ports are the devices through which data is
|
|
transferred between the &os; host computer and the terminal.
|
|
Several kinds of serial ports exist. Before purchasing or
|
|
constructing a cable, make sure it will fit the ports on the
|
|
terminal and on the &os; system.</para>
|
|
|
|
<para>Most terminals have <acronym>DB-25</acronym> ports.
|
|
Personal computers may have <acronym>DB-25</acronym> or
|
|
<acronym>DB-9</acronym> ports. A multiport serial card may
|
|
have <acronym>RJ-12</acronym> or <acronym>RJ-45/</acronym>
|
|
ports. See the documentation that accompanied the hardware
|
|
for specifications on the kind of port or visually verify the
|
|
type of port.</para>
|
|
|
|
<para>In &os;, each serial port is accessed through an entry in
|
|
<filename>/dev</filename>. There are two different kinds of
|
|
entries:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Call-in ports are named
|
|
<filename>/dev/ttyu<replaceable>N</replaceable></filename>
|
|
where <replaceable>N</replaceable> is the port number,
|
|
starting from zero. If a terminal is connected to the
|
|
first serial port (<filename>COM1</filename>), use
|
|
<filename>/dev/ttyu0</filename> to refer to the terminal.
|
|
If the terminal is on the second serial port
|
|
(<filename>COM2</filename>), use
|
|
<filename>/dev/ttyu1</filename>, and so forth. Generally,
|
|
the call-in port is used for terminals. Call-in ports
|
|
require that the serial line assert the <quote>Data
|
|
Carrier Detect</quote> signal to work correctly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Call-out ports are named
|
|
<filename>/dev/cuau<replaceable>N</replaceable></filename>
|
|
on &os; versions 10.x and higher and
|
|
<filename>/dev/cuad<replaceable>N</replaceable></filename>
|
|
on &os; versions 9.x and lower. Call-out ports are
|
|
usually not used for terminals, but are used for modems.
|
|
The call-out port can be used if the serial cable or the
|
|
terminal does not support the <quote>Data Carrier
|
|
Detect</quote> signal.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>&os; also provides initialization devices
|
|
(<filename>/dev/ttyu<replaceable>N</replaceable>.init</filename>
|
|
and
|
|
<filename>/dev/cuau<replaceable>N</replaceable>.init</filename>
|
|
or
|
|
<filename>/dev/cuad<replaceable>N</replaceable>.init</filename>)
|
|
and locking devices
|
|
(<filename>/dev/ttyu<replaceable>N</replaceable>.lock</filename>
|
|
and
|
|
<filename>/dev/cuau<replaceable>N</replaceable>.lock</filename>
|
|
or
|
|
<filename>/dev/cuad<replaceable>N</replaceable>.lock</filename>).
|
|
The initialization devices are used to initialize
|
|
communications port parameters each time a port is opened,
|
|
such as <literal>crtscts</literal> for modems which use
|
|
<literal>RTS/CTS</literal> signaling for flow control. The
|
|
locking devices are used to lock flags on ports to prevent
|
|
users or programs changing certain parameters. Refer to
|
|
&man.termios.4;, &man.sio.4;, and &man.stty.1; for information
|
|
on terminal settings, locking and initializing devices, and
|
|
setting terminal options, respectively.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="serial-hw-config">
|
|
<title>Serial Port Configuration</title>
|
|
|
|
<para>By default, &os; supports four serial ports which are
|
|
commonly known as <filename>COM1</filename>,
|
|
<filename>COM2</filename>, <filename>COM3</filename>, and
|
|
<filename>COM4</filename>. &os; also supports dumb multi-port
|
|
serial interface cards, such as the BocaBoard 1008 and 2016,
|
|
as well as more intelligent multi-port cards such as those
|
|
made by Digiboard. However, the default kernel only looks for
|
|
the standard <filename>COM</filename> ports.</para>
|
|
|
|
<para>To see if the system recognizes the serial ports, look for
|
|
system boot messages that start with
|
|
<literal>uart</literal>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>grep uart /var/run/dmesg.boot</userinput></screen>
|
|
|
|
<para>If the system does not recognize all of the needed serial
|
|
ports, additional entries can be added to
|
|
<filename>/boot/device.hints</filename>. This file already
|
|
contains <literal>hint.uart.0.*</literal> entries for
|
|
<filename>COM1</filename> and <literal>hint.uart.1.*</literal>
|
|
entries for <filename>COM2</filename>. When adding a port
|
|
entry for <filename>COM3</filename> use
|
|
<literal>0x3E8</literal>, and for <filename>COM4</filename>
|
|
use <literal>0x2E8</literal>. Common <acronym>IRQ</acronym>
|
|
addresses are <literal>5</literal> for
|
|
<filename>COM3</filename> and <literal>9</literal> for
|
|
<filename>COM4</filename>.</para>
|
|
|
|
<indexterm><primary><filename>ttyu</filename></primary></indexterm>
|
|
<indexterm><primary><filename>cuau</filename></primary></indexterm>
|
|
|
|
<para>To determine the default set of terminal
|
|
<acronym>I/O</acronym> settings used by the port, specify its
|
|
device name. This example determines the settings for the
|
|
call-in port on <filename>COM2</filename>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>stty -a -f /dev/<replaceable>ttyu1</replaceable></userinput></screen>
|
|
|
|
<para>System-wide initialization of serial devices is controlled
|
|
by <filename>/etc/rc.d/serial</filename>. This file affects
|
|
the default settings of serial devices. To change the
|
|
settings for a device, use <command>stty</command>. By
|
|
default, the changed settings are in effect until the device
|
|
is closed and when the device is reopened, it goes back to the
|
|
default set. To permanently change the default set, open and
|
|
adjust the settings of the initialization device. For
|
|
example, to turn on <option>CLOCAL</option> mode, 8 bit
|
|
communication, and <option>XON/XOFF</option> flow control for
|
|
<filename>ttyu5</filename>, type:</para>
|
|
|
|
<screen>&prompt.root; <userinput>stty -f /dev/ttyu5.init clocal cs8 ixon ixoff</userinput></screen>
|
|
|
|
<indexterm>
|
|
<primary>rc files</primary>
|
|
<secondary><filename>rc.serial</filename></secondary>
|
|
</indexterm>
|
|
|
|
<para>To prevent certain settings from being changed by an
|
|
application, make adjustments to the locking device. For
|
|
example, to lock the speed of <filename>ttyu5</filename> to
|
|
57600 bps, type:</para>
|
|
|
|
<screen>&prompt.root; <userinput>stty -f /dev/ttyu5.lock 57600</userinput></screen>
|
|
|
|
<para>Now, any application that opens <filename>ttyu5</filename>
|
|
and tries to change the speed of the port will be stuck with
|
|
57600 bps.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="term">
|
|
<info>
|
|
<title>Terminals</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<personname>
|
|
<firstname>Sean</firstname>
|
|
<surname>Kelly</surname>
|
|
</personname>
|
|
<contrib>Contributed by </contrib> <!--in July 1996 -->
|
|
</author>
|
|
</authorgroup>
|
|
</info>
|
|
|
|
<indexterm><primary>terminals</primary></indexterm>
|
|
|
|
<para>Terminals provide a convenient and low-cost way to access
|
|
a &os; system when not at the computer's console or on a
|
|
connected network. This section describes how to use terminals
|
|
with &os;.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>The ability to establish a login session on a serial port
|
|
still exists in nearly every &unix;-like operating system
|
|
today, including &os;. 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
|
|
<command>xterm</command> window.</para>
|
|
|
|
<para>Many terminals can be attached to a &os; system. An older
|
|
spare computer can be used as a terminal wired into a more
|
|
powerful computer running &os;. This can turn what might
|
|
otherwise be a single-user computer into a powerful
|
|
multiple-user system.</para>
|
|
|
|
<para>&os; supports three types of terminals:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Dumb terminals</term>
|
|
<listitem>
|
|
<para>Dumb terminals are specialized hardware that connect
|
|
to computers over serial lines. They are called
|
|
<quote>dumb</quote> 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.</para>
|
|
|
|
<para>There are hundreds of kinds of dumb terminals made by
|
|
many manufacturers, and just about any kind will work with
|
|
&os;. Some high-end terminals can even display graphics,
|
|
but only certain software packages can take advantage of
|
|
these advanced features.</para>
|
|
|
|
<para>Dumb terminals are popular in work environments where
|
|
workers do not need access to graphical
|
|
applications.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Computers Acting as Terminals</term>
|
|
<listitem>
|
|
<para>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 <firstterm>terminal emulation</firstterm>
|
|
software to run on the computer.</para>
|
|
|
|
<para>This configuration can be useful. For example, if one
|
|
user is busy working at the &os; 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 &os; system.</para>
|
|
|
|
<para>There are at least two utilities in the base-system of
|
|
&os; that can be used to work through a serial connection:
|
|
&man.cu.1; and &man.tip.1;.</para>
|
|
|
|
<para>For example, to connect from a client system that runs
|
|
&os; to the serial connection of another system:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cu -l <replaceable>serial-port-device</replaceable></userinput></screen>
|
|
|
|
<para>Replace <replaceable>serial-port-device</replaceable>
|
|
with the device name of the connected serial port. These
|
|
device files are called
|
|
<filename>/dev/cuau<replaceable>N</replaceable></filename>
|
|
on &os; versions 10.x and higher and
|
|
<filename>/dev/cuad<replaceable>N</replaceable></filename>
|
|
on &os; versions 9.x and lower. In either case,
|
|
<replaceable>N</replaceable> is the serial port number,
|
|
starting from zero. This means that
|
|
<filename>COM1</filename> is
|
|
<filename>/dev/cuau0</filename> or
|
|
<filename>/dev/cuad0</filename> in &os;.</para>
|
|
|
|
<para>Additional programs are available through the Ports
|
|
Collection, such as
|
|
<package>comms/minicom</package>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>X Terminals</term>
|
|
<listitem>
|
|
<para>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 <application>&xorg;</application>
|
|
application.</para>
|
|
|
|
<para>This chapter does not cover the setup, configuration,
|
|
or use of X terminals.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<sect2 xml:id="term-config">
|
|
<title>Terminal Configuration</title>
|
|
|
|
<para>This section describes how to configure a &os; 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.</para>
|
|
|
|
<para>In &os;, <command>init</command> reads
|
|
<filename>/etc/ttys</filename> and starts a
|
|
<command>getty</command> process on the available terminals.
|
|
The <command>getty</command> process is responsible for
|
|
reading a login name and starting the <command>login</command>
|
|
program. The ports on the &os; system which allow logins are
|
|
listed in <filename>/etc/ttys</filename>. For example, the
|
|
first virtual console, <filename>ttyv0</filename>, 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 <filename>/dev</filename> entry is listed without the
|
|
<literal>/dev</literal> part. For example,
|
|
<filename>/dev/ttyv0</filename> is listed as
|
|
<literal>ttyv0</literal>.</para>
|
|
|
|
<para>The default <filename>/etc/ttys</filename> configures
|
|
support for the first four serial ports,
|
|
<filename>ttyu0</filename> through
|
|
<filename>ttyu3</filename>:</para>
|
|
|
|
<programlisting>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</programlisting>
|
|
|
|
<para>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 <literal>on</literal> and, if needed, to
|
|
change the port's <literal>secure</literal> setting. If the
|
|
terminal is connected to another port, add an entry for the
|
|
port.</para>
|
|
|
|
<para><xref linkend="ex-etc-ttys"/> configures two terminals in
|
|
<filename>/etc/ttys</filename>. The first entry configures a
|
|
Wyse-50 connected to <filename>COM2</filename>. The second
|
|
entry configures an old computer running
|
|
<application>Procomm</application> terminal software emulating
|
|
a VT-100 terminal. The computer is connected to the sixth
|
|
serial port on a multi-port serial card.</para>
|
|
|
|
<example xml:id="ex-etc-ttys">
|
|
<title>Configuring Terminal Entries</title>
|
|
|
|
<programlisting>ttyu1<co xml:id="co-ttys-line1col1"/> "/usr/libexec/getty std.38400"<co xml:id="co-ttys-line1col2"/> wy50<co xml:id="co-ttys-line1col3"/> on<co xml:id="co-ttys-line1col4"/> insecure<co xml:id="co-ttys-line1col5"/>
|
|
ttyu5 "/usr/libexec/getty std.19200" vt100 on insecure</programlisting>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="co-ttys-line1col1">
|
|
<para>The first field specifies the device name of the
|
|
serial terminal.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-ttys-line1col2">
|
|
<para>The second field tells <command>getty</command> to
|
|
initialize and open the line, set the line speed, prompt
|
|
for a user name, and then execute the
|
|
<command>login</command> program. The optional
|
|
<firstterm>getty type</firstterm> configures
|
|
characteristics on the terminal line, like
|
|
<acronym>bps</acronym> rate and parity. The available
|
|
getty types are listed in
|
|
<filename>/etc/gettytab</filename>. In almost all
|
|
cases, the getty types that start with
|
|
<literal>std</literal> will work for hardwired terminals
|
|
as these entries ignore parity. There is a
|
|
<literal>std</literal> entry for each
|
|
<acronym>bps</acronym> rate from 110 to 115200. Refer
|
|
to &man.gettytab.5; for more information.</para>
|
|
|
|
<para>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.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-ttys-line1col3">
|
|
<para>The third field is the type of terminal. For
|
|
dial-up ports, <literal>unknown</literal> or
|
|
<literal>dialup</literal> is typically used since users
|
|
may dial up with practically any type of terminal or
|
|
software. Since the terminal type does not change for
|
|
hardwired terminals, a real terminal type from
|
|
<filename>/etc/termcap</filename> can be specified. For
|
|
this example, the Wyse-50 uses the real terminal type
|
|
while the computer running
|
|
<application>Procomm</application> is set to emulate a
|
|
VT-100.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-ttys-line1col4">
|
|
<para>The fourth field specifies if the port should be
|
|
enabled. To enable logins on this port, this field must
|
|
be set to <literal>on</literal>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-ttys-line1col5">
|
|
<para>The final field is used to specify whether the port
|
|
is secure. Marking a port as <literal>secure</literal>
|
|
means that it is trusted enough to allow <systemitem
|
|
class="username">root</systemitem> to login from that
|
|
port. Insecure ports do not allow <systemitem
|
|
class="username">root</systemitem> logins. On an
|
|
insecure port, users must login from unprivileged
|
|
accounts and then use <command>su</command> or a similar
|
|
mechanism to gain superuser privileges, as described in
|
|
<xref linkend="users-superuser"/>. For security
|
|
reasons, it is recommended to change this setting to
|
|
<literal>insecure</literal>.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
</example>
|
|
|
|
<para>After making any changes to
|
|
<filename>/etc/ttys</filename>, send a SIGHUP (hangup) signal
|
|
to the <command>init</command> process to force it to re-read
|
|
its configuration file:</para>
|
|
|
|
<screen>&prompt.root; <userinput>kill -HUP 1</userinput></screen>
|
|
|
|
<para>Since <command>init</command> is always the first process
|
|
run on a system, it always has a process <acronym>ID</acronym>
|
|
of <literal>1</literal>.</para>
|
|
|
|
<para>If everything is set up correctly, all cables are in
|
|
place, and the terminals are powered up, a
|
|
<command>getty</command> process should now be running on each
|
|
terminal and login prompts should be available on each
|
|
terminal.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="term-debug">
|
|
<title>Troubleshooting the Connection</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>Make sure the cable is connected firmly to both the
|
|
terminal and the &os; computer. Make sure it is the right
|
|
kind of cable.</para>
|
|
|
|
<para>Make sure the terminal and &os; agree on the
|
|
<acronym>bps</acronym> 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.</para>
|
|
|
|
<para>Use <command>ps</command> to make sure that a
|
|
<command>getty</command> process is running and serving the
|
|
terminal. For example, the following listing shows that a
|
|
<command>getty</command> is running on the second serial port,
|
|
<filename>ttyu1</filename>, and is using the
|
|
<literal>std.38400</literal> entry in
|
|
<filename>/etc/gettytab</filename>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>ps -axww|grep ttyu</userinput>
|
|
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyu1</screen>
|
|
|
|
<para>If no <command>getty</command> process is running, make
|
|
sure the port is enabled in <filename>/etc/ttys</filename>.
|
|
Remember to run <command>kill -HUP 1</command> after modifying
|
|
<filename>/etc/ttys</filename>.</para>
|
|
|
|
<para>If the <command>getty</command> 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 <filename>/etc/ttys</filename> from
|
|
<literal>std.38400</literal> to
|
|
<literal>3wire.38400</literal>, then run <command>kill -HUP
|
|
1</command> after modifying <filename>/etc/ttys</filename>.
|
|
The <literal>3wire</literal> entry is similar to
|
|
<literal>std</literal>, but ignores hardware handshaking. The
|
|
baud rate may need to be reduced or software flow control
|
|
enabled when using <literal>3wire</literal> to prevent buffer
|
|
overflows.</para>
|
|
|
|
<para>If garbage appears instead of a login prompt, make sure
|
|
the terminal and &os; agree on the <acronym>bps</acronym> rate
|
|
and parity settings. Check the <command>getty</command>
|
|
processes to make sure the correct
|
|
<replaceable>getty</replaceable> type is in use. If not, edit
|
|
<filename>/etc/ttys</filename> and run <command>kill
|
|
-HUP 1</command>.</para>
|
|
|
|
<para>If characters appear doubled and the password appears when
|
|
typed, switch the terminal, or the terminal emulation
|
|
software, from <quote>half duplex</quote> or <quote>local
|
|
echo</quote> to <quote>full duplex.</quote></para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="dialup">
|
|
<info>
|
|
<title>Dial-in Service</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<personname>
|
|
<firstname>Guy</firstname>
|
|
<surname>Helmer</surname>
|
|
</personname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<personname>
|
|
<firstname>Sean</firstname>
|
|
<surname>Kelly</surname>
|
|
</personname>
|
|
<contrib>Additions by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</info>
|
|
|
|
<indexterm><primary>dial-in service</primary></indexterm>
|
|
|
|
<para>Configuring a &os; system for dial-in service is similar to
|
|
configuring terminals, except that modems are used instead of
|
|
terminal devices. &os; supports both external and internal
|
|
modems.</para>
|
|
|
|
<para>External modems are more convenient because they often can
|
|
be configured via parameters stored in non-volatile
|
|
<acronym>RAM</acronym> and they usually provide lighted
|
|
indicators that display the state of important
|
|
<acronym>RS-232</acronym> signals, indicating whether the modem
|
|
is operating properly.</para>
|
|
|
|
<para>Internal modems usually lack non-volatile
|
|
<acronym>RAM</acronym>, so their configuration may be limited to
|
|
setting <acronym>DIP</acronym> switches. If the internal modem
|
|
has any signal indicator lights, they are difficult to view when
|
|
the system's cover is in place.</para>
|
|
|
|
<indexterm><primary>modem</primary></indexterm>
|
|
|
|
<para>When using an external modem, a proper cable is needed. A
|
|
standard <acronym>RS-232C</acronym> serial cable should
|
|
suffice.</para>
|
|
|
|
<para>&os; needs the <acronym>RTS</acronym> and
|
|
<acronym>CTS</acronym> signals for flow control at speeds above
|
|
2400 bps, the <acronym>CD</acronym> signal to detect when a
|
|
call has been answered or the line has been hung up, and the
|
|
<acronym>DTR</acronym> signal to reset the modem after a session
|
|
is complete. Some cables are wired without all of the needed
|
|
signals, so if a login session does not go away when the line
|
|
hangs up, there may be a problem with the cable. Refer to <xref
|
|
linkend="term-cables-null"/> for more information about these
|
|
signals.</para>
|
|
|
|
<para>Like other &unix;-like operating systems, &os; uses the
|
|
hardware signals to find out when a call has been answered or a
|
|
line has been hung up and to hangup and reset the modem after a
|
|
call. &os; avoids sending commands to the modem or watching for
|
|
status reports from the modem.</para>
|
|
|
|
<para>&os; supports the <acronym>NS8250</acronym>,
|
|
<acronym>NS16450</acronym>, <acronym>NS16550</acronym>, and
|
|
<acronym>NS16550A</acronym>-based <acronym>RS-232C</acronym>
|
|
(<acronym>CCITT</acronym> V.24) communications interfaces. The
|
|
8250 and 16450 devices have single-character buffers. The 16550
|
|
device provides a 16-character buffer, which allows for better
|
|
system performance. Bugs in plain 16550 devices prevent the use
|
|
of the 16-character buffer, so use 16550A devices if possible.
|
|
Because single-character-buffer devices require more work by the
|
|
operating system than the 16-character-buffer devices,
|
|
16550A-based serial interface cards are preferred. If the
|
|
system has many active serial ports or will have a heavy load,
|
|
16550A-based cards are better for low-error-rate
|
|
communications.</para>
|
|
|
|
<para>The rest of this section demonstrates how to configure a
|
|
modem to receive incoming connections, how to communicate with
|
|
the modem, and offers some troubleshooting tips.</para>
|
|
|
|
<sect2 xml:id="dialup-ttys">
|
|
<title>Modem Configuration</title>
|
|
|
|
<indexterm><primary>getty</primary></indexterm>
|
|
<para>As with terminals, <command>init</command> spawns a
|
|
<command>getty</command> process for each configured serial
|
|
port used for dial-in connections. When a user dials the
|
|
modem's line and the modems connect, the <quote>Carrier
|
|
Detect</quote> signal is reported by the modem. The kernel
|
|
notices that the carrier has been detected and instructs
|
|
<command>getty</command> to open the port and display a
|
|
<prompt>login:</prompt> prompt at the specified initial line
|
|
speed. In a typical configuration, if garbage characters are
|
|
received, usually due to the modem's connection speed being
|
|
different than the configured speed, <command>getty</command>
|
|
tries adjusting the line speeds until it receives reasonable
|
|
characters. After the user enters their login name,
|
|
<command>getty</command> executes <command>login</command>,
|
|
which completes the login process by asking for the user's
|
|
password and then starting the user's shell.</para>
|
|
|
|
<indexterm>
|
|
<primary><command>/usr/bin/login</command></primary>
|
|
</indexterm>
|
|
|
|
<para>There are two schools of thought regarding dial-up modems.
|
|
One configuration method is to set the modems and systems so
|
|
that no matter at what speed a remote user dials in, the
|
|
dial-in <acronym>RS-232</acronym> interface runs at a locked
|
|
speed. The benefit of this configuration is that the remote
|
|
user always sees a system login prompt immediately. The
|
|
downside is that the system does not know what a user's true
|
|
data rate is, so full-screen programs like
|
|
<application>Emacs</application> will not adjust their
|
|
screen-painting methods to make their response better for
|
|
slower connections.</para>
|
|
|
|
<para>The second method is to configure the
|
|
<acronym>RS-232</acronym> interface to vary its speed based on
|
|
the remote user's connection speed. Because
|
|
<command>getty</command> does not understand any particular
|
|
modem's connection speed reporting, it gives a
|
|
<prompt>login:</prompt> message at an initial speed and
|
|
watches the characters that come back in response. If the
|
|
user sees junk, they should press <keycap>Enter</keycap> until
|
|
they see a recognizable prompt. If the data rates do not
|
|
match, <command>getty</command> sees anything the user types
|
|
as junk, tries the next speed, and gives the
|
|
<prompt>login:</prompt> prompt again. This procedure normally
|
|
only takes a keystroke or two before the user sees a good
|
|
prompt. This login sequence does not look as clean as the
|
|
locked-speed method, but a user on a low-speed connection
|
|
should receive better interactive response from full-screen
|
|
programs.</para>
|
|
|
|
<para>When locking a modem's data communications rate at a
|
|
particular speed, no changes to
|
|
<filename>/etc/gettytab</filename> should be needed. However,
|
|
for a matching-speed configuration, additional entries may be
|
|
required in order to define the speeds to use for the modem.
|
|
This example configures a 14.4 Kbps modem with a top
|
|
interface speed of 19.2 Kbps using 8-bit, no parity
|
|
connections. It configures <command>getty</command> to start
|
|
the communications rate for a V.32bis connection at
|
|
19.2 Kbps, then cycles through 9600 bps,
|
|
2400 bps, 1200 bps, 300 bps, and back to
|
|
19.2 Kbps. Communications rate cycling is implemented
|
|
with the <literal>nx=</literal> (next table) capability. Each
|
|
line uses a <literal>tc=</literal> (table continuation) entry
|
|
to pick up the rest of the settings for a particular data
|
|
rate.</para>
|
|
|
|
<programlisting>#
|
|
# Additions for a V.32bis Modem
|
|
#
|
|
um|V300|High Speed Modem at 300,8-bit:\
|
|
:nx=V19200:tc=std.300:
|
|
un|V1200|High Speed Modem at 1200,8-bit:\
|
|
:nx=V300:tc=std.1200:
|
|
uo|V2400|High Speed Modem at 2400,8-bit:\
|
|
:nx=V1200:tc=std.2400:
|
|
up|V9600|High Speed Modem at 9600,8-bit:\
|
|
:nx=V2400:tc=std.9600:
|
|
uq|V19200|High Speed Modem at 19200,8-bit:\
|
|
:nx=V9600:tc=std.19200:</programlisting>
|
|
|
|
<para>For a 28.8 Kbps modem, or to take advantage of
|
|
compression on a 14.4 Kbps modem, use a higher
|
|
communications rate, as seen in this example:</para>
|
|
|
|
<programlisting>#
|
|
# Additions for a V.32bis or V.34 Modem
|
|
# Starting at 57.6 Kbps
|
|
#
|
|
vm|VH300|Very High Speed Modem at 300,8-bit:\
|
|
:nx=VH57600:tc=std.300:
|
|
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
|
|
:nx=VH300:tc=std.1200:
|
|
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
|
|
:nx=VH1200:tc=std.2400:
|
|
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
|
|
:nx=VH2400:tc=std.9600:
|
|
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
|
|
:nx=VH9600:tc=std.57600:</programlisting>
|
|
|
|
<para>For a slow <acronym>CPU</acronym> or a heavily loaded
|
|
system without 16550A-based serial ports, this configuration
|
|
may produce <errorname>sio</errorname>
|
|
<quote>silo</quote> errors at 57.6 Kbps.</para>
|
|
|
|
<indexterm>
|
|
<primary><filename>/etc/ttys</filename></primary>
|
|
</indexterm>
|
|
|
|
<para>The configuration of <filename>/etc/ttys</filename> is
|
|
similar to <xref linkend="ex-etc-ttys"/>, but a different
|
|
argument is passed to <command>getty</command> and
|
|
<literal>dialup</literal> is used for the terminal type.
|
|
Replace <replaceable>xxx</replaceable> with the process
|
|
<command>init</command> will run on the device:</para>
|
|
|
|
<programlisting>ttyu0 "/usr/libexec/getty <replaceable>xxx</replaceable>" dialup on</programlisting>
|
|
|
|
<para>The <literal>dialup</literal> terminal type can be
|
|
changed. For example, setting <literal>vt102</literal> as the
|
|
default terminal type allows users to use
|
|
<acronym>VT102</acronym> emulation on their remote
|
|
systems.</para>
|
|
|
|
<para>For a locked-speed configuration, specify the speed with
|
|
a valid type listed in <filename>/etc/gettytab</filename>.
|
|
This example is for a modem whose port speed is locked at
|
|
19.2 Kbps:</para>
|
|
|
|
<programlisting>ttyu0 "/usr/libexec/getty std.<replaceable>19200</replaceable>" dialup on</programlisting>
|
|
|
|
<para>In a matching-speed configuration, the entry needs to
|
|
reference the appropriate beginning <quote>auto-baud</quote>
|
|
entry in <filename>/etc/gettytab</filename>. To continue the
|
|
example for a matching-speed modem that starts at
|
|
19.2 Kbps, use this entry:</para>
|
|
|
|
<programlisting>ttyu0 "/usr/libexec/getty V19200" dialup on</programlisting>
|
|
|
|
<para>After editing <filename>/etc/ttys</filename>, wait until
|
|
the modem is properly configured and connected before
|
|
signaling <command>init</command>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>kill -HUP 1</userinput></screen>
|
|
|
|
<indexterm>
|
|
<primary>rc files</primary>
|
|
<secondary><filename>rc.serial</filename></secondary>
|
|
</indexterm>
|
|
|
|
<para>High-speed modems, like <acronym>V.32</acronym>,
|
|
<acronym>V.32bis</acronym>, and <acronym>V.34</acronym>
|
|
modems, use hardware (<literal>RTS/CTS</literal>) flow
|
|
control. Use <command>stty</command> to set the hardware flow
|
|
control flag for the modem port. This example sets the
|
|
<varname>crtscts</varname> flag on <filename>COM2</filename>'s
|
|
dial-in and dial-out initialization devices:</para>
|
|
|
|
<screen>&prompt.root; <userinput>stty -f /dev/ttyu1.init crtscts</userinput>
|
|
&prompt.root; <userinput>stty -f /dev/cuau1.init crtscts</userinput></screen>
|
|
</sect2>
|
|
|
|
<!--
|
|
Comment out for now. If this is still needed, the example should
|
|
either be updated or the section modified to be more generic
|
|
e.g. refer to the modem's manual
|
|
<sect2>
|
|
<title>Modem Settings</title>
|
|
|
|
<para>For a modem whose parameters may be permanently set in
|
|
non-volatile RAM, a terminal program such as
|
|
<command>tip</command> can be used to set the parameters.
|
|
Connect to the modem using the same communications speed as
|
|
the initial speed <command>getty</command> will use and
|
|
configure the modem's non-volatile RAM to match these
|
|
requirements:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><acronym>CD</acronym> asserted when connected.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><acronym>DTR</acronym> asserted for operation and
|
|
dropping DTR hangs up the line and resets the
|
|
modem.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><acronym>CTS</acronym> transmitted data flow
|
|
control.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Disable <acronym>XON/XOFF</acronym> flow
|
|
control.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><acronym>RTS</acronym> received data flow
|
|
control.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Quiet mode (no result codes).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No command echo.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Read the documentation for the modem to find out
|
|
which commands and/or DIP switch settings are needed.</para>
|
|
|
|
<para>For example, to set the above parameters on a &usrobotics;
|
|
&sportster; 14,400 external modem, give these commands to
|
|
the modem:</para>
|
|
|
|
<programlisting>ATZ
|
|
AT&C1&D2&H1&I0&R2&W</programlisting>
|
|
|
|
<para>Other settings can be adjusted in the modem, such as
|
|
whether it will use V.42bis and/or MNP5 compression.</para>
|
|
|
|
<para>The &usrobotics; &sportster; 14,400 external modem also
|
|
has some DIP switches that need to be set. Other modems,
|
|
may need these settings:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Switch 1: UP — DTR Normal</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 2: N/A (Verbal Result Codes/Numeric Result
|
|
Codes)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 3: UP — Suppress Result Codes</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 4: DOWN — No echo, offline
|
|
commands</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 5: UP — Auto Answer</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 6: UP — Carrier Detect Normal</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 7: UP — Load NVRAM Defaults</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Switch 8: N/A (Smart Mode/Dumb Mode)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Result codes should be disabled/suppressed for dial-up
|
|
modems to avoid problems that can occur if
|
|
<command>getty</command> mistakenly gives a
|
|
<prompt>login:</prompt> prompt to a modem that is in command
|
|
mode and the modem echoes the command or returns a result
|
|
code. This sequence can result in an extended, silly
|
|
conversation between <command>getty</command> and the
|
|
modem.</para>
|
|
|
|
<para>For a locked-speed configuration, configure the modem to
|
|
maintain a constant modem-to-computer data rate independent
|
|
of the communications rate. On a &usrobotics; &sportster;
|
|
14,400 external modem, these commands will lock the
|
|
modem-to-computer data rate at the speed used to issue the
|
|
commands:</para>
|
|
|
|
<programlisting>ATZ
|
|
AT&B1&W</programlisting>
|
|
|
|
<para>For a variable-speed configuration, configure the modem
|
|
to adjust its serial port data rate to match the incoming
|
|
call rate. On a &usrobotics; &sportster; 14,400 external
|
|
modem, these commands will lock the modem's error-corrected
|
|
data rate to the speed used to issue the commands, while
|
|
allowing the serial port rate to vary for
|
|
non-error-corrected connections:</para>
|
|
|
|
<programlisting>ATZ
|
|
AT&B2&W</programlisting>
|
|
|
|
<para>Most high-speed modems provide commands to view the
|
|
modem's current operating parameters in a somewhat
|
|
human-readable fashion. On the &usrobotics; &sportster;
|
|
14,400 external modem, <command>ATI5</command> displays the
|
|
settings that are stored in the non-volatile RAM. To see the
|
|
true operating parameters of the modem, as influenced by the
|
|
modem's DIP switch settings, use <command>ATZ</command> and
|
|
then <command>ATI4</command>.</para>
|
|
|
|
<para>For a different brand of modem, check the modem's manual
|
|
to see how to double-check the modem's configuration
|
|
parameters.</para>
|
|
</sect2>
|
|
-->
|
|
|
|
<sect2>
|
|
<title>Troubleshooting</title>
|
|
|
|
<para>This section provides a few tips for troubleshooting a
|
|
dial-up modem that will not connect to a &os; system.</para>
|
|
|
|
<para>Hook up the modem to the &os; system and boot the system.
|
|
If the modem has status indication lights, watch to see
|
|
whether the modem's <acronym>DTR</acronym> indicator lights
|
|
when the <prompt>login:</prompt> prompt appears on the
|
|
system's console. If it lights up, that should mean that &os;
|
|
has started a <command>getty</command> process on the
|
|
appropriate communications port and is waiting for the modem
|
|
to accept a call.</para>
|
|
|
|
<para>If the <acronym>DTR</acronym> indicator does not light,
|
|
login to the &os; system through the console and type
|
|
<command>ps ax</command> to see if &os; is running a
|
|
<command>getty</command> process on the correct port:</para>
|
|
|
|
<screen> 114 ?? I 0:00.10 /usr/libexec/getty V19200 <replaceable>ttyu0</replaceable></screen>
|
|
|
|
<para>If the second column contains a <literal>d0</literal>
|
|
instead of a <literal>??</literal> and the modem has not
|
|
accepted a call yet, this means that <command>getty</command>
|
|
has completed its open on the communications port. This could
|
|
indicate a problem with the cabling or a misconfigured modem
|
|
because <command>getty</command> should not be able to open
|
|
the communications port until the carrier detect signal has
|
|
been asserted by the modem.</para>
|
|
|
|
<para>If no <command>getty</command> processes are waiting to
|
|
open the port, double-check that the entry for the port is
|
|
correct in <filename>/etc/ttys</filename>. Also, check
|
|
<filename>/var/log/messages</filename> to see if there are
|
|
any log messages from <command>init</command> or
|
|
<command>getty</command>.</para>
|
|
|
|
<para>Next, try dialing into the system. Be sure to use 8 bits,
|
|
no parity, and 1 stop bit on the remote system. If a prompt
|
|
does not appear right away, or the prompt shows garbage, try
|
|
pressing <keycap>Enter</keycap> about once per second. If
|
|
there is still no <prompt>login:</prompt> prompt,
|
|
try sending a <command>BREAK</command>. When using a
|
|
high-speed modem, try dialing again after locking the
|
|
dialing modem's interface speed.</para>
|
|
|
|
<para>If there is still no <prompt>login:</prompt> prompt, check
|
|
<filename>/etc/gettytab</filename> again and double-check
|
|
that:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The initial capability name specified in the entry in
|
|
<filename>/etc/ttys</filename> matches the name of a
|
|
capability in <filename>/etc/gettytab</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Each <literal>nx=</literal> entry matches another
|
|
<filename>gettytab</filename> capability name.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Each <literal>tc=</literal> entry matches another
|
|
<filename>gettytab</filename> capability name.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If the modem on the &os; system will not answer, make
|
|
sure that the modem is configured to answer the phone when
|
|
<acronym>DTR</acronym> is asserted. If the modem seems to be
|
|
configured correctly, verify that the
|
|
<acronym>DTR</acronym> line is asserted by checking the
|
|
modem's indicator lights.</para>
|
|
|
|
<para>If it still does not work, try sending an email
|
|
to the &a.questions; describing the modem and the
|
|
problem.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="dialout">
|
|
<title>Dial-out Service</title>
|
|
|
|
<indexterm><primary>dial-out service</primary></indexterm>
|
|
|
|
<para>The following are tips for getting the host to connect over
|
|
the modem to another computer. This is appropriate for
|
|
establishing a terminal session with a remote host.</para>
|
|
|
|
<para>This kind of connection can be helpful to get a file on the
|
|
Internet if there are problems using PPP. If PPP is not
|
|
working, use the terminal session to FTP the needed file. Then
|
|
use zmodem to transfer it to the machine.</para>
|
|
|
|
<sect2 xml:id="hayes-unsupported">
|
|
<title>Using a Stock Hayes Modem</title>
|
|
|
|
<para>A generic Hayes dialer is built into
|
|
<command>tip</command>. Use <literal>at=hayes</literal> in
|
|
<filename>/etc/remote</filename>.</para>
|
|
|
|
<para>The Hayes driver is not smart enough to recognize some of
|
|
the advanced features of newer modems messages like
|
|
<literal>BUSY</literal>, <literal>NO DIALTONE</literal>, or
|
|
<literal>CONNECT 115200</literal>. Turn those messages off
|
|
when using <command>tip</command> with
|
|
<command>ATX0&W</command>.</para>
|
|
|
|
<para>The dial timeout for <command>tip</command> is 60
|
|
seconds. The modem should use something less, or else
|
|
<command>tip</command> will think there is a communication
|
|
problem. Try <command>ATS7=45&W</command>.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="direct-at">
|
|
<title>Using <literal>AT</literal> Commands</title>
|
|
|
|
<indexterm>
|
|
<primary><filename>/etc/remote</filename></primary>
|
|
</indexterm>
|
|
<para>Create a <quote>direct</quote> entry in
|
|
<filename>/etc/remote</filename>. For example, if the modem
|
|
is hooked up to the first serial port,
|
|
<filename>/dev/cuau0</filename>, use the following
|
|
line:</para>
|
|
|
|
<programlisting>cuau0:dv=/dev/cuau0:br#19200:pa=none</programlisting>
|
|
|
|
<para>Use the highest <acronym>bps</acronym> rate the modem
|
|
supports in the <literal>br</literal> capability. Then, type
|
|
<command>tip cuau0</command> to connect to the modem.</para>
|
|
|
|
<para>Or, use <command>cu</command> as <systemitem
|
|
class="username">root</systemitem> with the following
|
|
command:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cu -l<replaceable>line</replaceable> -s<replaceable>speed</replaceable></userinput></screen>
|
|
|
|
<para><replaceable>line</replaceable> is the serial port, such
|
|
as <filename>/dev/cuau0</filename>, and
|
|
<replaceable>speed</replaceable> is the speed, such as
|
|
<literal>57600</literal>. When finished entering the AT
|
|
commands, type <command>~.</command> to exit.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="gt-failure">
|
|
<title>The <literal>@</literal> Sign Does Not Work</title>
|
|
|
|
<para>The <literal>@</literal> sign in the phone number
|
|
capability tells <command>tip</command> to look in
|
|
<filename>/etc/phones</filename> for a phone number. But, the
|
|
<literal>@</literal> sign is also a special character in
|
|
capability files like <filename>/etc/remote</filename>, so it
|
|
needs to be escaped with a backslash:</para>
|
|
|
|
<programlisting>pn=\@</programlisting>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="dial-command-line">
|
|
<title>Dialing from the Command Line</title>
|
|
|
|
<para>Put a <quote>generic</quote> entry in
|
|
<filename>/etc/remote</filename>. For example:</para>
|
|
|
|
<programlisting>tip115200|Dial any phone number at 115200 bps:\
|
|
:dv=/dev/cuau0:br#115200:at=hayes:pa=none:du:
|
|
tip57600|Dial any phone number at 57600 bps:\
|
|
:dv=/dev/cuau0:br#57600:at=hayes:pa=none:du:</programlisting>
|
|
|
|
<para>This should now work:</para>
|
|
|
|
<screen>&prompt.root; <userinput>tip -115200 5551234</userinput></screen>
|
|
|
|
<para>Users who prefer <command>cu</command> over
|
|
<command>tip</command>, can use a generic
|
|
<literal>cu</literal> entry:</para>
|
|
|
|
<programlisting>cu115200|Use cu to dial any number at 115200bps:\
|
|
:dv=/dev/cuau1:br#57600:at=hayes:pa=none:du:</programlisting>
|
|
|
|
<para>and type:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cu 5551234 -s 115200</userinput></screen>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="set-bps">
|
|
<title>Setting the <acronym>bps</acronym> Rate</title>
|
|
|
|
<para>Put in an entry for <literal>tip1200</literal> or
|
|
<literal>cu1200</literal>, but go ahead and use whatever
|
|
<acronym>bps</acronym> rate is appropriate with the
|
|
<literal>br</literal> capability.
|
|
<command>tip</command> thinks a good default is 1200 bps
|
|
which is why it looks for a <literal>tip1200</literal> entry.
|
|
1200 bps does not have to be used, though.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="terminal-server">
|
|
<title>Accessing a Number of Hosts Through a Terminal
|
|
Server</title>
|
|
|
|
<para>Rather than waiting until connected and typing
|
|
<command>CONNECT <replaceable>host</replaceable></command>
|
|
each time, use <command>tip</command>'s <literal>cm</literal>
|
|
capability. For example, these entries in
|
|
<filename>/etc/remote</filename> will let you type
|
|
<command>tip pain</command> or <command>tip muffin</command>
|
|
to connect to the hosts <systemitem>pain</systemitem> or
|
|
<systemitem>muffin</systemitem>, and <command>tip
|
|
deep13</command> to connect to the terminal server.</para>
|
|
|
|
<programlisting>pain|pain.deep13.com|Forrester's machine:\
|
|
:cm=CONNECT pain\n:tc=deep13:
|
|
muffin|muffin.deep13.com|Frank's machine:\
|
|
:cm=CONNECT muffin\n:tc=deep13:
|
|
deep13:Gizmonics Institute terminal server:\
|
|
:dv=/dev/cuau2:br#38400:at=hayes:du:pa=none:pn=5551234:</programlisting>
|
|
|
|
</sect2>
|
|
|
|
<sect2 xml:id="tip-multiline">
|
|
<title>Using More Than One Line with
|
|
<command>tip</command></title>
|
|
|
|
<para>This is often a problem where a university has several
|
|
modem lines and several thousand students trying to use
|
|
them.</para>
|
|
|
|
<para>Make an entry in <filename>/etc/remote</filename> and use
|
|
<literal>@</literal> for the <literal>pn</literal>
|
|
capability:</para>
|
|
|
|
<programlisting>big-university:\
|
|
:pn=\@:tc=dialout
|
|
dialout:\
|
|
:dv=/dev/cuau3:br#9600:at=courier:du:pa=none:</programlisting>
|
|
|
|
<para>Then, list the phone numbers in
|
|
<filename>/etc/phones</filename>:</para>
|
|
|
|
<programlisting>big-university 5551111
|
|
big-university 5551112
|
|
big-university 5551113
|
|
big-university 5551114</programlisting>
|
|
|
|
<para><command>tip</command> will try each number in the listed
|
|
order, then give up. To keep retrying, run
|
|
<command>tip</command> in a <literal>while</literal>
|
|
loop.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="multi-controlp">
|
|
<title>Using the Force Character</title>
|
|
|
|
<para><keycombo action="simul">
|
|
<keycap>Ctrl</keycap>
|
|
<keycap>P</keycap>
|
|
</keycombo> is the default <quote>force</quote> character,
|
|
used to tell <command>tip</command> that the next character is
|
|
literal data. The force character can be set to any other
|
|
character with the <command>~s</command> escape, which means
|
|
<quote>set a variable.</quote></para>
|
|
|
|
<para>Type
|
|
<command>~sforce=<replaceable>single-char</replaceable></command>
|
|
followed by a newline. <replaceable>single-char</replaceable>
|
|
is any single character. If
|
|
<replaceable>single-char</replaceable> is left out, then the
|
|
force character is the null character, which is accessed by
|
|
typing
|
|
<keycombo action="simul">
|
|
<keycap>Ctrl</keycap><keycap>2</keycap>
|
|
</keycombo>
|
|
or <keycombo action="simul">
|
|
<keycap>Ctrl</keycap><keycap>Space</keycap>
|
|
</keycombo>. A pretty good value for
|
|
<replaceable>single-char</replaceable> is
|
|
<keycombo action="simul">
|
|
<keycap>Shift</keycap>
|
|
<keycap>Ctrl</keycap>
|
|
<keycap>6</keycap>
|
|
</keycombo>, which is only used on some terminal
|
|
servers.</para>
|
|
|
|
<para>To change the force character, specify the following in
|
|
<filename>~/.tiprc</filename>:</para>
|
|
|
|
<programlisting>force=<replaceable>single-char</replaceable></programlisting>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="uppercase">
|
|
<title>Upper Case Characters</title>
|
|
|
|
<para>This happens when
|
|
<keycombo action="simul">
|
|
<keycap>Ctrl</keycap>
|
|
<keycap>A</keycap>
|
|
</keycombo> is pressed, which is <command>tip</command>'s
|
|
<quote>raise character</quote>, specially designed for people
|
|
with broken caps-lock keys. Use <command>~s</command> to set
|
|
<literal>raisechar</literal> to something reasonable. It can
|
|
be set to be the same as the force character, if neither
|
|
feature is used.</para>
|
|
|
|
<para>Here is a sample <filename>~/.tiprc</filename> for
|
|
<application>Emacs</application> users who need to type
|
|
<keycombo action="simul">
|
|
<keycap>Ctrl</keycap>
|
|
<keycap>2</keycap>
|
|
</keycombo> and <keycombo action="simul">
|
|
<keycap>Ctrl</keycap>
|
|
<keycap>A</keycap>
|
|
</keycombo>:</para>
|
|
|
|
<programlisting>force=^^
|
|
raisechar=^^</programlisting>
|
|
|
|
<para>The <literal>^^</literal> is
|
|
<keycombo action="simul">
|
|
<keycap>Shift</keycap><keycap>Ctrl</keycap><keycap>6</keycap>
|
|
</keycombo>.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 xml:id="tip-filetransfer">
|
|
<title>File Transfers with <command>tip</command></title>
|
|
|
|
<para>When talking to another &unix;-like operating system,
|
|
files can be sent and received using <command>~p</command>
|
|
(put) and <command>~t</command> (take). These commands run
|
|
<command>cat</command> and <command>echo</command> on the
|
|
remote system to accept and send files. The syntax is:</para>
|
|
|
|
<cmdsynopsis>
|
|
<command>~p</command>
|
|
<arg choice="plain">local-file</arg>
|
|
<arg choice="opt">remote-file</arg>
|
|
</cmdsynopsis>
|
|
|
|
<cmdsynopsis>
|
|
<command>~t</command>
|
|
<arg choice="plain">remote-file</arg>
|
|
<arg choice="opt">local-file</arg>
|
|
</cmdsynopsis>
|
|
|
|
<para>There is no error checking, so another protocol, like
|
|
zmodem, should probably be used.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="zmodem-tip">
|
|
<title>Using <application>zmodem</application> with
|
|
<command>tip</command>?</title>
|
|
|
|
<para>To receive files, start the sending program on the remote
|
|
end. Then, type <command>~C rz</command> to begin receiving
|
|
them locally.</para>
|
|
|
|
<para>To send files, start the receiving program on the remote
|
|
end. Then, type <command>~C sz
|
|
<replaceable>files</replaceable></command> to send them to the
|
|
remote system.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 xml:id="serialconsole-setup">
|
|
<info>
|
|
<title>Setting Up the Serial Console</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<personname>
|
|
<firstname>Kazutaka</firstname>
|
|
<surname>YOKOTA</surname>
|
|
</personname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<personname>
|
|
<firstname>Bill</firstname>
|
|
<surname>Paul</surname>
|
|
</personname>
|
|
<contrib>Based on a document by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
</info>
|
|
|
|
<indexterm><primary>serial console</primary></indexterm>
|
|
|
|
<para>&os; has the ability to boot a system with a dumb
|
|
terminal on a serial port as a console. This configuration is
|
|
useful for system administrators who wish to install &os; on
|
|
machines that have no keyboard or monitor attached, and
|
|
developers who want to debug the kernel or device
|
|
drivers.</para>
|
|
|
|
<para>As described in <xref linkend="boot"/>, &os; employs a three
|
|
stage bootstrap. The first two stages are in the boot block
|
|
code which is stored at the beginning of the &os; slice on the
|
|
boot disk. The boot block then loads and runs the boot loader
|
|
as the third stage code.</para>
|
|
|
|
<para>In order to set up booting from a serial console, the boot
|
|
block code, the boot loader code, and the kernel need to be
|
|
configured.</para>
|
|
|
|
<sect2 xml:id="serialconsole-howto-fast">
|
|
<title>Quick Serial Console Configuration</title>
|
|
|
|
<para>This section provides a fast overview of setting up the
|
|
serial console. This procedure can be used when the dumb
|
|
terminal is connected to <filename>COM1</filename>.</para>
|
|
|
|
<procedure>
|
|
<title>Configuring a Serial Console on
|
|
<filename>COM1</filename></title>
|
|
|
|
<step>
|
|
<para>Connect the serial cable to
|
|
<filename>COM1</filename> and the controlling
|
|
terminal.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>To configure boot messages to display on the serial
|
|
console, issue the following command as the
|
|
superuser:</para>
|
|
|
|
<screen>&prompt.root; echo 'console="comconsole"' >> /boot/loader.conf</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Edit <filename>/etc/ttys</filename> and change
|
|
<literal>off</literal> to <literal>on</literal> and
|
|
<literal>dialup</literal> to <literal>vt100</literal> for
|
|
the <filename>ttyu0</filename> entry. Otherwise, a
|
|
password will not be required to connect via the serial
|
|
console, resulting in a potential security hole.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Reboot the system to see if the changes took
|
|
effect.</para>
|
|
</step>
|
|
|
|
</procedure>
|
|
|
|
<para>If a different configuration is required, see the next
|
|
section for a more in-depth configuration explanation.</para>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="serialconsole-howto">
|
|
<title>In-Depth Serial Console Configuration</title>
|
|
|
|
<para>This section provides a more detailed explanation of the
|
|
steps needed to setup a serial console in &os;.</para>
|
|
|
|
<procedure>
|
|
<title>Configuring a Serial Console</title>
|
|
|
|
<step>
|
|
<para>Prepare a serial cable.</para>
|
|
|
|
<indexterm><primary>null-modem cable</primary></indexterm>
|
|
|
|
<para>Use either a null-modem cable or a standard serial
|
|
cable and a null-modem adapter. See <xref
|
|
linkend="term-cables-null"/> for a discussion on serial
|
|
cables.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Unplug the keyboard.</para>
|
|
|
|
<para>Many systems probe for the keyboard during the
|
|
Power-On Self-Test (<acronym>POST</acronym>) and will
|
|
generate an error if the keyboard is not detected. Some
|
|
machines will refuse to boot until the keyboard is plugged
|
|
in.</para>
|
|
|
|
<para>If the computer complains about the error, but boots
|
|
anyway, no further configuration is needed.</para>
|
|
|
|
<para>If the computer refuses to boot without a keyboard
|
|
attached, configure the <acronym>BIOS</acronym> so that it
|
|
ignores this error. Consult the motherboard's manual for
|
|
details on how to do this.</para>
|
|
|
|
<tip>
|
|
<para>Try setting the keyboard to <quote>Not
|
|
installed</quote> in the <acronym>BIOS</acronym>.
|
|
This setting tells the <acronym>BIOS</acronym> not to
|
|
probe for a keyboard at power-on so it should not
|
|
complain if the keyboard is absent. If that option is
|
|
not present in the <acronym>BIOS</acronym>, look for an
|
|
<quote>Halt on Error</quote> option instead. Setting
|
|
this to <quote>All but Keyboard</quote> or to <quote>No
|
|
Errors</quote> will have the same effect.</para>
|
|
</tip>
|
|
|
|
<para>If the system has a &ps2; mouse, unplug it as well.
|
|
&ps2; mice share some hardware with the keyboard and
|
|
leaving the mouse plugged in can fool the keyboard probe
|
|
into thinking the keyboard is still there.</para>
|
|
|
|
<note>
|
|
<para>While most systems will boot without a keyboard,
|
|
quite a few will not boot without a graphics adapter.
|
|
Some systems can be configured to boot with no graphics
|
|
adapter by changing the <quote>graphics adapter</quote>
|
|
setting in the <acronym>BIOS</acronym> configuration to
|
|
<quote>Not installed</quote>. Other systems do not
|
|
support this option and will refuse to boot if there is
|
|
no display hardware in the system. With these machines,
|
|
leave some kind of graphics card plugged in, even if it
|
|
is just a junky mono board. A monitor does not need to
|
|
be attached.</para>
|
|
</note>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Plug a dumb terminal, an old computer with a modem
|
|
program, or the serial port on another &unix; box into the
|
|
serial port.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Add the appropriate <literal>hint.sio.*</literal>
|
|
entries to <filename>/boot/device.hints</filename> for the
|
|
serial port. Some multi-port cards also require kernel
|
|
configuration options. Refer to &man.sio.4; for the
|
|
required options and device hints for each supported
|
|
serial port.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Create <filename>boot.config</filename> in the root
|
|
directory of the <literal>a</literal> partition on the
|
|
boot drive.</para>
|
|
|
|
<para>This file instructs the boot block code how to boot
|
|
the system. In order to activate the serial console, one
|
|
or more of the following options are needed. When using
|
|
multiple options, include them all on the same
|
|
line:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>-h</option></term>
|
|
|
|
<listitem>
|
|
<para>Toggles between the internal and serial
|
|
consoles. Use this to switch console devices. For
|
|
instance, to boot from the internal (video) console,
|
|
use <option>-h</option> to direct the boot loader
|
|
and the kernel to use the serial port as its console
|
|
device. Alternatively, to boot from the serial
|
|
port, use <option>-h</option> to tell the boot
|
|
loader and the kernel to use the video display as
|
|
the console instead.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-D</option></term>
|
|
|
|
<listitem>
|
|
<para>Toggles between the single and dual console
|
|
configurations. In the single configuration, the
|
|
console will be either the internal console (video
|
|
display) or the serial port, depending on the state
|
|
of <option>-h</option>. In the dual console
|
|
configuration, both the video display and the
|
|
serial port will become the console at the same
|
|
time, regardless of the state of
|
|
<option>-h</option>. However, the dual console
|
|
configuration takes effect only while the boot
|
|
block is running. Once the boot loader gets
|
|
control, the console specified by
|
|
<option>-h</option> becomes the only
|
|
console.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-P</option></term>
|
|
|
|
<listitem>
|
|
<para>Makes the boot block probe the keyboard. If no
|
|
keyboard is found, the <option>-D</option> and
|
|
<option>-h</option> options are automatically
|
|
set.</para>
|
|
|
|
<note>
|
|
<para>Due to space constraints in the current
|
|
version of the boot blocks, <option>-P</option> is
|
|
capable of detecting extended keyboards only.
|
|
Keyboards with less than 101 keys and without F11
|
|
and F12 keys may not be detected. Keyboards on
|
|
some laptops may not be properly found because of
|
|
this limitation. If this is the case, do not use
|
|
<option>-P</option>.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Use either <option>-P</option> to select the console
|
|
automatically or <option>-h</option> to activate the
|
|
serial console. Refer to &man.boot.8; and
|
|
&man.boot.config.5; for more details.</para>
|
|
|
|
<para>The options, except for <option>-P</option>, are
|
|
passed to the boot loader. The boot loader will
|
|
determine whether the internal video or the serial port
|
|
should become the console by examining the state of
|
|
<option>-h</option>. This means that if
|
|
<option>-D</option> is specified but <option>-h</option>
|
|
is not specified in <filename>/boot.config</filename>, the
|
|
serial port can be used as the console only during the
|
|
boot block as the boot loader will use the internal video
|
|
display as the console.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Boot the machine.</para>
|
|
|
|
<para>When &os; starts, the boot blocks echo the contents of
|
|
<filename>/boot.config</filename> to the console. For
|
|
example:</para>
|
|
|
|
<screen>/boot.config: -P
|
|
Keyboard: no</screen>
|
|
|
|
<para>The second line appears only if <option>-P</option> is
|
|
in <filename>/boot.config</filename> and indicates the
|
|
presence or absence of the keyboard. These messages go
|
|
to either the serial or internal console, or both,
|
|
depending on the option in
|
|
<filename>/boot.config</filename>:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Options</entry>
|
|
<entry align="left">Message goes to</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>none</entry>
|
|
<entry>internal console</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-h</option></entry>
|
|
<entry>serial console</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-D</option></entry>
|
|
<entry>serial and internal consoles</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-Dh</option></entry>
|
|
<entry>serial and internal consoles</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-P</option>, keyboard present</entry>
|
|
<entry>internal console</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-P</option>, keyboard absent</entry>
|
|
<entry>serial console</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>After the message, there will be a small pause before
|
|
the boot blocks continue loading the boot loader and
|
|
before any further messages are printed to the console.
|
|
Under normal circumstances, there is no need to interrupt
|
|
the boot blocks, but one can do so in order to make sure
|
|
things are set up correctly.</para>
|
|
|
|
<para>Press any key, other than <keycap>Enter</keycap>, at
|
|
the console to interrupt the boot process. The boot
|
|
blocks will then prompt for further action:</para>
|
|
|
|
<screen>>> FreeBSD/i386 BOOT
|
|
Default: 0:ad(0,a)/boot/loader
|
|
boot:</screen>
|
|
|
|
<para>Verify that the above message appears on either the
|
|
serial or internal console, or both, according to the
|
|
options in <filename>/boot.config</filename>. If the
|
|
message appears in the correct console, press
|
|
<keycap>Enter</keycap> to continue the boot
|
|
process.</para>
|
|
|
|
<para>If there is no prompt on the serial terminal,
|
|
something is wrong with the settings. Enter
|
|
<option>-h</option> then <keycap>Enter</keycap> or
|
|
<keycap>Return</keycap> to tell the boot block (and then
|
|
the boot loader and the kernel) to choose the serial port
|
|
for the console. Once the system is up, go back and check
|
|
what went wrong.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>During the third stage of the boot process, one can still
|
|
switch between the internal console and the serial console by
|
|
setting appropriate environment variables in the boot loader.
|
|
See &man.loader.8; for more
|
|
information.</para>
|
|
|
|
<note>
|
|
<para>This line in <filename>/boot/loader.conf</filename> or
|
|
<filename>/boot/loader.conf.local</filename> configures the
|
|
boot loader and the kernel to send their boot messages to
|
|
the serial console, regardless of the options in
|
|
<filename>/boot.config</filename>:</para>
|
|
|
|
<programlisting>console="comconsole"</programlisting>
|
|
|
|
<para>That line should be the first line of
|
|
<filename>/boot/loader.conf</filename> so that boot messages
|
|
are displayed on the serial console as early as
|
|
possible.</para>
|
|
|
|
<para>If that line does not exist, or if it is set to
|
|
<literal>console="vidconsole"</literal>, the boot loader and
|
|
the kernel will use whichever console is indicated by
|
|
<option>-h</option> in the boot block. See
|
|
&man.loader.conf.5; for more information.</para>
|
|
|
|
<para>At the moment, the boot loader has no option
|
|
equivalent to <option>-P</option> in the boot block, and
|
|
there is no provision to automatically select the internal
|
|
console and the serial console based on the presence of the
|
|
keyboard.</para>
|
|
</note>
|
|
|
|
<tip>
|
|
<para>While it is not required, it is possible to provide a
|
|
<command>login</command> prompt over the serial line. To
|
|
configure this, edit the entry for the serial port in
|
|
<filename>/etc/ttys</filename> using the instructions in
|
|
<xref linkend="term-config"/>. If the speed of the serial
|
|
port has been changed, change <literal>std.9600</literal> to
|
|
match the new setting.</para>
|
|
</tip>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Setting a Faster Serial Port Speed</title>
|
|
|
|
<para>By default, the serial port settings are 9600 baud, 8
|
|
bits, no parity, and 1 stop bit. To change the default
|
|
console speed, use one of the following options:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Edit <filename>/etc/make.conf</filename> and set
|
|
<varname>BOOT_COMCONSOLE_SPEED</varname> to the new
|
|
console speed. Then, recompile and install the boot
|
|
blocks and the boot loader:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cd /sys/boot</userinput>
|
|
&prompt.root; <userinput>make clean</userinput>
|
|
&prompt.root; <userinput>make</userinput>
|
|
&prompt.root; <userinput>make install</userinput></screen>
|
|
|
|
<para>If the serial console is configured in some other way
|
|
than by booting with <option>-h</option>, or if the serial
|
|
console used by the kernel is different from the one used
|
|
by the boot blocks, add the following option, with the
|
|
desired speed, to a custom kernel configuration file and
|
|
compile a new kernel:</para>
|
|
|
|
<programlisting>options CONSPEED=<replaceable>19200</replaceable></programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Add the
|
|
<option>-S<replaceable>19200</replaceable></option> boot
|
|
option to <filename>/boot.config</filename>, replacing
|
|
<replaceable>19200</replaceable> with the speed to
|
|
use.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Add the following options to
|
|
<filename>/boot/loader.conf</filename>. Replace
|
|
<replaceable>115200</replaceable> with the speed to
|
|
use.</para>
|
|
|
|
<programlisting>boot_multicons="YES"
|
|
boot_serial="YES"
|
|
comconsole_speed="<replaceable>115200</replaceable>"
|
|
console="comconsole,vidconsole"</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2 xml:id="serialconsole-ddb">
|
|
<title>Entering the DDB Debugger from the Serial Line</title>
|
|
|
|
<para>To configure the ability to drop into the kernel debugger
|
|
from the serial console, add the following options to a custom
|
|
kernel configuration file and compile the kernel using the
|
|
instructions in <xref linkend="kernelconfig"/>. Note that
|
|
while this is useful for remote diagnostics, it is also
|
|
dangerous if a spurious BREAK is generated on the serial port.
|
|
Refer to &man.ddb.4; and &man.ddb.8; for more information
|
|
about the kernel debugger.</para>
|
|
|
|
<programlisting>options BREAK_TO_DEBUGGER
|
|
options DDB</programlisting>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|