Date: Wed, 7 May 2014 20:37:49 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44790 - head/en_US.ISO8859-1/books/handbook/serialcomms Message-ID: <201405072037.s47Kbnhw073820@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405072037.s47Kbnhw073820>