svn commit: r44790 - head/en_US.ISO8859-1/books/handbook/serialcomms
Dru Lavigne
dru at FreeBSD.org
Wed May 7 20:37:49 UTC 2014
Author: dru
Date: Wed May 7 20:37:48 2014
New Revision: 44790
URL: http://svnweb.freebsd.org/changeset/doc/44790
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml Wed May 7 19:51:05 2014 (r44789)
+++ head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml Wed May 7 20:37:48 2014 (r44790)
@@ -104,112 +104,110 @@
</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>
+ 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>
+ <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
+ 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>
+ <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>
+ <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>
+ <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>
@@ -494,13 +492,13 @@
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>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
@@ -516,10 +514,10 @@
<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>
+ <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>
@@ -527,17 +525,17 @@
<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>
+ 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
+ <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>)
@@ -553,9 +551,9 @@
<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>
+ &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">
@@ -564,12 +562,11 @@
<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>
+ <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
@@ -577,17 +574,18 @@
<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
+ <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>
+ <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>
@@ -599,20 +597,19 @@
<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
+ <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>
+ <screen>&prompt.root; <userinput>stty -f /dev/ttyu5.init clocal cs8 ixon ixoff</userinput></screen>
<indexterm>
<primary>rc files</primary>
@@ -620,15 +617,15 @@
</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>
+ 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>
@@ -761,10 +758,10 @@
<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>
+ 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
@@ -774,132 +771,128 @@
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,
+ 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>
+ <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
+ <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>
+ <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"/>
+ <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>
+ <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">
@@ -916,8 +909,8 @@ ttyu5 "/usr/libexec/getty std.19200"
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>
+ 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
@@ -926,11 +919,11 @@ ttyu5 "/usr/libexec/getty std.19200"
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
+ <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>
@@ -996,37 +989,40 @@ ttyu5 "/usr/libexec/getty std.19200"
<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
+ <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>
+ <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>
+ 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>
+ <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
@@ -1034,24 +1030,24 @@ ttyu5 "/usr/libexec/getty std.19200"
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>
+ <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>
@@ -1060,79 +1056,72 @@ ttyu5 "/usr/libexec/getty std.19200"
<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
+ 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>
+ 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 confiuration 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
+ One confiuration 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
+ <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>
+ 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>#
+ <programlisting>#
# Additions for a V.32bis Modem
#
um|V300|High Speed Modem at 300,8-bit:\
@@ -1146,11 +1135,11 @@ up|V9600|High Speed Modem at 9600,8-bit:
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>
+ <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>#
+ <programlisting>#
# Additions for a V.32bis or V.34 Modem
# Starting at 57.6 Kbps
#
@@ -1165,70 +1154,65 @@ vp|VH9600|Very High Speed Modem at 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>
+ <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>
+
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list