aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml')
-rw-r--r--en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml2742
1 files changed, 0 insertions, 2742 deletions
diff --git a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
deleted file mode 100644
index 3cb7be6640..0000000000
--- a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
+++ /dev/null
@@ -1,2742 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml,v 1.18 2000/06/08 01:56:19 jim Exp $
--->
-
-<chapter id="serialcomms">
- <title>Serial Communications</title>
-
- <sect1>
- <title>Synopsis</title>
-
- <para>UNIX has always had support for serial communications. In fact,
- 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
- <quote>terminal</quote> consisted of a 10-character-per-second serial
- printer and a keyboard. This chapter will cover some of the ways in
- which FreeBSD uses serial communications.</para>
- </sect1>
-
- <sect1 id="serial">
- <title>Serial Basics</title>
-
- <para><emphasis>Assembled from FAQ.</emphasis></para>
-
- <para>This section should give you some general information about serial
- ports. If you do not find what you want here, check into the Terminal
- and Dial-up sections of the handbook.</para>
-
- <para>The <filename>ttyd<replaceable>X</replaceable></filename> (or
- <filename>cuaa<replaceable>X</replaceable></filename>) device is the
- regular device you will want to open for your applications. When a
- process opens the device, it will have a default set of terminal I/O
- settings. You can see these settings with the command</para>
-
- <screen>&prompt.root; <userinput>stty -a -f /dev/ttyd1</userinput></screen>
-
- <para>When you change the settings to this device, the settings are in
- effect until the device is closed. When it is reopened, it goes back to
- the default set. To make changes to the default set, you can open and
- adjust the settings of the <quote>initial state</quote> device. For
- example, to turn on <acronym>CLOCAL</acronym> mode, 8 bits, and
- <emphasis>XON/XOFF</emphasis> flow control by default for ttyd5,
- do:</para>
-
- <screen>&prompt.root; <userinput>stty -f /dev/ttyid5 clocal cs8 ixon ixoff</userinput></screen>
-
- <para>A good place to do this is in <filename>/etc/rc.serial</filename>.
- Now, an application will have these settings by default when it opens
- <filename>ttyd5</filename>. It can still change these settings to its
- liking, though.</para>
-
- <para>You can also prevent certain settings from being changed by an
- application by making adjustments to the <quote>lock state</quote>
- device. For example, to lock the speed of <filename>ttyd5</filename> to
- 57600 bps, do</para>
-
- <screen>&prompt.root; <userinput>stty -f /dev/ttyld5 57600</userinput></screen>
-
- <para>Now, an application that opens <filename>ttyd5</filename> and tries
- to change the speed of the port will be stuck with 57600 bps.</para>
-
- <para>Naturally, you should make the initial state and lock state devices
- writable only by <username>root</username>. The
- <filename>MAKEDEV</filename> script does <emphasis>not</emphasis> do
- this when it creates the device entries.</para>
- </sect1>
-
- <sect1 id="term">
- <title>Terminals</title>
-
- <para><emphasis>Contributed by &a.kelly; 28 July 1996</emphasis></para>
-
- <para>Terminals provide a convenient and low-cost way to access the power
- of your FreeBSD system when you are not at the computer's console or on
- a connected network. This section describes how to use terminals with
- FreeBSD.</para>
-
- <sect2 id="term-uses">
- <title>Uses and Types of Terminals</title>
-
- <para>The original Unix systems did not have consoles. Instead, people
- logged in and ran programs through terminals that were connected to
- the computer's serial ports. It is quite similar to using a modem and
- some terminal software to dial into a remote system to do text-only
- work.</para>
-
- <para>Today's PCs have consoles capable of high quality graphics, but
- the ability to establish a login session on a serial port still exists
- in nearly every Unix-style operating system today; FreeBSD is no
- exception. By using a terminal attached to a unused serial port, you
- can log in and run any text program that you would normally run on the
- console or in an <command>xterm</command> window in the X Window
- System.</para>
-
- <para>For the business user, you can attach many terminals to a FreeBSD
- system and place them on your employees' desktops. For a home user, a
- spare computer such as an older IBM PC or a Macintosh can be a
- terminal wired into a more powerful computer running FreeBSD. You can
- turn what might otherwise be a single-user computer into a powerful
- multiple user system.</para>
-
- <para>For FreeBSD, there are three kinds of terminals:</para>
-
- <itemizedlist>
- <listitem>
- <para><link linkend="term-dumb">Dumb terminals</link></para>
- </listitem>
-
- <listitem>
- <para><link linkend="term-pcs">PCs acting as terminals</link></para>
- </listitem>
-
- <listitem>
- <para><link linkend="term-x">X terminals</link></para>
- </listitem>
- </itemizedlist>
-
- <para>The remaining subsections describe each kind.</para>
-
- <sect3 id="term-dumb">
- <title>Dumb Terminals</title>
-
- <para>Dumb terminals are specialized pieces of hardware that let you
- 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. You cannot run any programs on
- them. It is the computer to which you connect them that has all the
- power to run text editors, compilers, email, games, and so
- forth.</para>
-
- <para>There are hundreds of kinds of dumb terminals made by many
- manufacturers, including Digital Equipment Corporation's VT-100 and
- Wyse's WY-75. Just about any kind will work with FreeBSD. Some
- high-end terminals can even display graphics, but only certain
- software packages can take advantage of these advanced
- features.</para>
-
- <para>Dumb terminals are popular in work environments where workers do
- not need access to graphic applications such as those provided by
- the X Window System.</para>
- </sect3>
-
- <sect3 id="term-pcs">
- <title>PCs Acting As Terminals</title>
-
- <para>If a <link linkend="term-dumb">dumb terminal</link> has just
- enough ability to display, send, and receive text, then certainly
- any spare personal computer can be a dumb terminal. All you need is
- the proper cable and some <emphasis>terminal emulation</emphasis>
- software to run on the computer.</para>
-
- <para>Such a configuration is popular in homes. For example, if your
- spouse is busy working on your FreeBSD system's console, you can do
- some text-only work at the same time from a less powerful personal
- computer hooked up as a terminal to the FreeBSD system.</para>
- </sect3>
-
- <sect3 id="term-x">
- <title>X Terminals</title>
-
- <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 X application.</para>
-
- <para>We introduce X terminals just for the sake of completeness.
- However, this chapter does <emphasis>not</emphasis> cover setup,
- configuration, or use of X terminals.</para>
- </sect3>
- </sect2>
-
- <sect2 id="term-cables-ports">
- <title>Cables and Ports</title>
-
- <para>To connect a terminal to your FreeBSD system, you need the right
- kind of cable and a serial port to which to connect it. This section
- tells you what to do. If you are already familiar with your terminal
- and the cable it requires, skip to <link
- linkend="term-config">Configuration</link>.</para>
-
- <sect3 id="term-cables">
- <title>Cables</title>
-
- <para>Because terminals use serial ports, you need to use
- serial&mdash;also known as RS-232C&mdash;cables to connect the
- terminal to the FreeBSD system.</para>
-
- <para>There are a couple of kinds of serial cables. Which one
- you'll use depends on the terminal you want to connect:</para>
-
- <itemizedlist>
- <listitem>
- <para>If you are connecting a personal computer to act as a
- terminal, use a <link linkend="term-null">null-modem</link>
- cable. A null-modem cable connects two computers or terminals
- together.</para>
- </listitem>
-
- <listitem>
- <para>If you have an actual terminal, your best source of
- information on what cable to use is the documentation that
- accompanied the terminal. If you do not have the documentation,
- then try a <link linkend="term-null">null-modem</link> cable.
- If that does not work, then try a <link
- linkend="term-std">standard</link> cable.</para>
- </listitem>
- </itemizedlist>
-
- <para>Also, the serial port on <emphasis>both</emphasis> the terminal
- and your FreeBSD system must have connectors that will fit the cable
- you are using.</para>
-
- <sect4 id="term-null">
- <title>Null-modem cables</title>
-
- <para>A null-modem cable passes some signals straight through, like
- <quote>signal ground,</quote> but switches other signals. For
- example, the <quote>send data</quote> pin on one end goes to the
- <quote>receive data</quote> pin on the other end.</para>
-
- <para>If you like making your own cables, here is a table showing a
- recommended way to construct a null-modem cable for use with
- terminals. This table shows the RS-232C signal names and the pin
- numbers on a DB-25 connector.</para>
-
- <informaltable frame="none">
- <tgroup cols="5">
- <thead>
- <row>
- <entry>Signal</entry>
- <entry>Pin #</entry>
- <entry></entry>
- <entry>Pin #</entry>
- <entry>Signal</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry>TxD</entry>
- <entry>2</entry>
- <entry>connects to</entry>
- <entry>3</entry>
- <entry>RxD</entry>
- </row>
-
- <row>
- <entry>RxD</entry>
- <entry>3</entry>
- <entry>connects to</entry>
- <entry>2</entry>
- <entry>TxD</entry>
- </row>
-
- <row>
- <entry>DTR</entry>
- <entry>20</entry>
- <entry>connects to</entry>
- <entry>6</entry>
- <entry>DSR</entry>
- </row>
-
- <row>
- <entry>DSR</entry>
- <entry>6</entry>
- <entry>connects to</entry>
- <entry>20</entry>
- <entry>DTR</entry>
- </row>
-
- <row>
- <entry>SG</entry>
- <entry>7</entry>
- <entry>connects to</entry>
- <entry>7</entry>
- <entry>SG</entry>
- </row>
-
- <row>
- <entry>DCD</entry>
- <entry>8</entry>
- <entry>connects to</entry>
- <entry>4</entry>
- <entry>RTS</entry>
- </row>
-
- <row>
- <entry>RTS</entry>
- <entry>4</entry>
- <entry></entry>
- <entry>5</entry>
- <entry>CTS</entry>
- </row>
-
- <row>
- <entry>CTS</entry>
- <entry>5</entry>
- <entry>connects to</entry>
- <entry>8</entry>
- <entry>DCD</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <note>
- <para>For DCD to RTS, connect pins 4 to 5 internally in the
- connector hood, and then to pin 8 in the remote
- hood.</para>
- </note>
- </sect4>
-
- <sect4 id="term-std">
- <title>Standard RS-232C Cables</title>
-
- <para>A standard serial cable passes all the RS-232C signals
- straight-through. That is, the <quote>send data</quote> pin on one
- end of the cable goes to the <quote>send data</quote> pin on the
- other end. This is the type of cable to connect a modem to your
- FreeBSD system, and the type of cable needed for some
- terminals.</para>
- </sect4>
- </sect3>
-
- <sect3 id="term-ports">
- <title>Ports</title>
-
- <para>Serial ports are the devices through which data is transferred
- between the FreeBSD host computer and the terminal. This section
- describes the kinds of ports that exist and how they are addressed
- in FreeBSD.</para>
-
- <sect4 id="term-portkinds">
- <title>Kinds of Ports</title>
-
- <para>Several kinds of serial ports exist. Before you purchase or
- construct a cable, you need to make sure it will fit the ports on
- your terminal and on the FreeBSD system.</para>
-
- <para>Most terminals will have DB25 ports. Personal computers,
- including PCs running FreeBSD, will have DB25 or DB9 ports. If you
- have a multiport serial card for your PC, you may have RJ-12 or
- RJ-45 ports.</para>
-
- <para>See the documentation that accompanied the hardware for
- specifications on the kind of port in use. A visual inspection of
- the port often works, too.</para>
- </sect4>
-
- <sect4 id="term-portnames">
- <title>Port Names</title>
-
- <para>In FreeBSD, you access each serial port through an entry in
- the <filename>/dev</filename> directory. There are two different
- kinds of entries:</para>
-
- <itemizedlist>
- <listitem>
- <para>Call-in ports are named
- <filename>/dev/ttyd<replaceable>X</replaceable></filename>
- where <replaceable>X</replaceable> is the port number,
- starting from zero. Generally, you use the call-in port for
- terminals. Call-in ports require that the serial line assert
- the data carrier detect (DCD) signal to work.</para>
- </listitem>
-
- <listitem>
- <para>Call-out ports are named
- <filename>/dev/cuaa<replaceable>X</replaceable></filename>.
- You usually do not use the call-out port for terminals, just
- for modems. You may use the call-out port if the serial cable
- or the terminal does not support the carrier detect
- signal.</para>
- </listitem>
- </itemizedlist>
-
- <para>See the &man.sio.4; manual page for more information.</para>
-
- <para>If you have connected a terminal to the first serial port
- (<devicename>COM1</devicename> in DOS parlance), then you want to
- use <filename>/dev/ttyd0</filename> to refer to the terminal. If
- it is on the second serial port (also known as
- <devicename>COM2</devicename>), it is
- <filename>/dev/ttyd1</filename>, and so forth.</para>
-
- <para>Note that you may have to configure your kernel to support
- each serial port, especially if you have a multiport serial card.
- See <link linkend="kernelconfig">Configuring the FreeBSD
- Kernel</link> for more information.</para>
- </sect4>
- </sect3>
- </sect2>
-
- <sect2 id="term-config">
- <title>Configuration</title>
-
- <para>This section describes what you need to configure on your FreeBSD
- system to enable a login session on a terminal. It assumes you have
- already configured your kernel to support the serial port to which the
- terminal is connected&mdash;and that you have connected it.</para>
-
- <para>In a nutshell, you need to tell the <command>init</command>
- process, which is responsible for process control and initialization,
- to start a <command>getty</command> process, which is responsible for
- reading a login name and starting the <command>login</command>
- program.</para>
-
- <para>To do so, you have to edit the <filename>/etc/ttys</filename>
- file. First, use the <command>su</command> command to become root.
- Then, make the following changes to
- <filename>/etc/ttys</filename>:</para>
-
- <procedure>
- <step>
- <para>Add an line to <filename>/etc/ttys</filename> for the entry in
- the <filename>/dev</filename> directory for the serial port if it
- is not already there.</para>
- </step>
-
- <step>
- <para>Specify that <filename>/usr/libexec/getty</filename> be run on
- the port, and specify the appropriate
- <replaceable>getty</replaceable> type from the
- <filename>/etc/gettytab</filename> file.</para>
- </step>
-
- <step>
- <para>Specify the default terminal type.</para>
- </step>
-
- <step>
- <para>Set the port to <quote>on.</quote></para>
- </step>
-
- <step>
- <para>Specify whether the port should be
- <quote>secure.</quote></para>
- </step>
-
- <step>
- <para>Force <command>init</command> to reread the
- <filename>/etc/ttys</filename> file.</para>
- </step>
- </procedure>
-
- <para>As an optional step, you may wish to create a custom
- <replaceable>getty</replaceable> type for use in step 2 by making an
- entry in <filename>/etc/gettytab</filename>. This document does
- not explain how to do so; you are encouraged to see the
- &man.gettytab.5; and the &man.getty.8; manual pages for more
- information.</para>
-
- <para>The remaining sections detail how to do these steps. We will use
- a running example throughout these sections to illustrate what we need
- to do. In our example, we will connect two terminals to the system: a
- Wyse-50 and a old 286 IBM PC running Procomm terminal software
- emulating a VT-100 terminal. We connect the Wyse to the second serial
- port and the 286 to the sixth serial port (a port on a multiport
- serial card).</para>
-
- <para>For more information on the <filename>/etc/ttys</filename>
- file, see the &man.ttys.5; manual page.</para>
-
- <sect3 id="term-etcttys">
- <title>Adding an Entry to <filename>/etc/ttys</filename></title>
-
- <para>First, you need to add an entry to the
- <filename>/etc/ttys</filename> file, unless one is already
- there.</para>
-
- <para>The <filename>/etc/ttys</filename> file lists all of the ports
- on your FreeBSD system where you want to allow logins. For example,
- the first virtual console <filename>ttyv0</filename> has an entry in
- this file. You can log in on the console using this entry. This
- file contains entries for the other virtual consoles, serial ports,
- and pseudo-ttys. For a hardwired terminal, just list the serial
- port's <filename>/dev</filename> entry without the
- <filename>/dev</filename> part.</para>
-
- <para>When you installed your FreeBSD system, the
- <filename>/etc/ttys</filename> file included entries for the first
- four serial ports: <filename>ttyd0</filename> through
- <filename>ttyd3</filename>. If you are attaching a terminal on one
- of those ports, you do not need to add an entry.</para>
-
- <para>In our example, we attached a Wyse-50 to the second serial port,
- <filename>ttyd1</filename>, which is already in the file. We need
- to add an entry for the 286 PC connected to the sixth serial port.
- Here is an excerpt of the <filename>/etc/ttys</filename> file after
- we add the new entry:</para>
-
- <programlisting>
-ttyd1 "/usr/libexec/getty std.9600" unknown off secure
-ttyd5</programlisting>
- </sect3>
-
- <sect3 id="term-getty">
- <title>Specifying the <replaceable>getty</replaceable> Type</title>
-
- <para>Next, we need to specify what program will be run to handle the
- logins on a terminal. For FreeBSD, the standard program to do that
- is <filename>/usr/libexec/getty</filename>. It is what provides the
- <prompt>login:</prompt> prompt.</para>
-
- <para>The program <command>getty</command> takes one (optional)
- parameter on its command line, the <replaceable>getty</replaceable>
- type. A <replaceable>getty</replaceable> type tells about
- characteristics on the terminal line, like bps rate and parity. The
- <command>getty</command> program reads these characteristics from
- the file <filename>/etc/gettytab</filename>.</para>
-
- <para>The file <filename>/etc/gettytab</filename> contains lots of
- entries for terminal lines both old and new. In almost all cases,
- the entries that start with the text <literal>std</literal> will
- work for hardwired terminals. These entries ignore parity. There is
- a <literal>std</literal> entry for each bps rate from 110 to 115200.
- Of course, you can add your own entries to this file. The manual
- page &man.gettytab.5; provides more
- information.</para>
-
- <para>When setting the <replaceable>getty</replaceable> type in the
- <filename>/etc/ttys</filename> file, make sure that the
- communications settings on the terminal match.</para>
-
- <para>For our example, the Wyse-50 uses no parity and connects at
- 38400 bps. The 286 PC uses no parity and connects at 19200 bps.
- Here is the <filename>/etc/ttys</filename> file so far (showing just
- the two terminals in which we are interested):</para>
-
- <programlisting>
-ttyd1 "/usr/libexec/getty std.38400" unknown off secure
-ttyd5 "/usr/libexec/getty std.19200"</programlisting>
-
- <para>Note that the second field&mdash;where we specify what program
- to run&mdash;appears in quotes. This is important, otherwise the
- type argument to <command>getty</command> might be interpreted as
- the next field.</para>
- </sect3>
-
- <sect3 id="term-deftermtype">
- <title>Specifying the Default Terminal Type</title>
-
- <para>The third field in the <filename>/etc/ttys</filename> file lists
- the default terminal type for the port. For dial-up ports, you
- typically put <literal>unknown</literal> or
- <literal>dialup</literal> in this field because users may dial up
- with practically any kind of terminal or software. For hardwired
- terminals, the terminal type does not change, so you can put a real
- terminal type in this field.</para>
-
- <para>Users will usually use the <command>tset</command> program in
- their <filename>.login</filename> or <filename>.profile</filename>
- files to check the terminal type and prompt for one if necessary.
- By setting a terminal type in the <filename>/etc/ttys</filename>
- file, users can forego such prompting.</para>
-
- <para>To find out what terminal types FreeBSD supports, see the
- file <filename>/usr/share/misc/termcap</filename>. It lists
- about 600 terminal types. You can add more if you wish. See
- the &man.termcap.5; manual page for information.</para>
-
- <para>In our example, the Wyse-50 is a Wyse-50 type of terminal
- (although it can emulate others, we will leave it in Wyse-50 mode).
- The 286 PC is running Procomm which will be set to emulate a VT-100.
- Here are the pertinent yet unfinished entries from the
- <filename>/etc/ttys</filename> file:</para>
-
- <programlisting>
-ttyd1 "/usr/libexec/getty std.38400" wy50 off secure
-ttyd5 "/usr/libexec/getty std.19200" vt100</programlisting>
- </sect3>
-
- <sect3 id="term-enable">
- <title>Enabling the Port</title>
-
- <para>The next field in <filename>/etc/ttys</filename>, the fourth
- field, tells whether to enable the port. Putting
- <literal>on</literal> here will have the <command>init</command>
- process start the program in the second field,
- <command>getty</command>, which will prompt for a login. If you put
- <literal>off</literal> in the fourth field, there will be no
- <command>getty</command>, and hence no logins on the port.</para>
-
- <para>So, naturally, you want an <literal>on</literal> in this field.
- Here again is the <filename>/etc/ttys</filename> file. We have
- turned each port <literal>on</literal>.</para>
-
- <programlisting>
-ttyd1 "/usr/libexec/getty std.38400" wy50 on secure
-ttyd5 "/usr/libexec/getty std.19200" vt100 on</programlisting>
- </sect3>
-
- <sect3 id="term-secure">
- <title>Specifying Secure Ports</title>
-
- <para>We have arrived at the last field (well, almost: there is an
- optional <literal>window</literal> specifier, but we will ignore
- that). The last field tells whether the port is secure.</para>
-
- <para>What does <quote>secure</quote> mean?</para>
-
- <para>It means that the root account (or any account with a user ID of
- 0) may login on the port. Insecure ports do not allow root to
- login.</para>
-
- <para>How do you use secure and insecure ports?</para>
-
- <para>By marking a port as insecure, the terminal to which it is
- connected will not allow root to login. People who know the root
- password to your FreeBSD system will first have to login using a
- regular user account. To gain superuser privileges, they will then
- have to use the <command>su</command> command.</para>
-
- <para>Because of this, you will have two records to help track down
- possible compromises of root privileges: both the
- <command>login</command> and the <command>su</command> command make
- records in the system log (and logins are also recorded in the
- <filename>wtmp</filename> file).</para>
-
- <para>By marking a port as secure, the terminal will allow root in.
- People who know the root password will just login as root. You will
- not have the potentially useful login and <command>su</command>
- command records.</para>
-
- <para>Which should you use?</para>
-
- <para>Just use <quote>insecure.</quote> Use <quote>insecure</quote>
- <emphasis>even</emphasis> for terminals <emphasis>not</emphasis> in
- public user areas or behind locked doors. It is quite easy to login
- and use <command>su</command> if you need superuser
- privileges.</para>
-
- <para>Here finally are the completed entries in the
- <filename>/etc/ttys</filename> file, with comments added to describe
- where the terminals are:</para>
-
- <programlisting>
-ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen
-ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom</programlisting>
- </sect3>
-
- <sect3 id="term-hup">
- <title>Force <command>init</command> to Reread
- <filename>/etc/ttys</filename></title>
-
- <para>When you boot FreeBSD, the first process,
- <command>init</command>, will read the
- <filename>/etc/ttys</filename> file and start the programs listed
- for each enabled port to prompt for logins.</para>
-
- <para>After you edit <filename>/etc/ttys</filename>, you do not want
- to have to reboot your system to get <command>init</command> to see
- the changes. So, <command>init</command> will reread
- <filename>/etc/ttys</filename> if it receives a SIGHUP (hangup)
- signal.</para>
-
- <para>So, after you have saved your changes to
- <filename>/etc/ttys</filename>, send <literal>SIGHUP</literal> to
- <command>init</command> by typing:</para>
-
- <screen>&prompt.root; <userinput>kill -HUP 1</userinput></screen>
-
- <para>(The <command>init</command> process <emphasis>always</emphasis>
- has process ID 1.)</para>
-
- <para>If everything is set up correctly, all cables are in place, and
- the terminals are powered up, you should see login prompts. Your
- terminals are ready for their first logins!</para>
- </sect3>
- </sect2>
-
- <sect2 id="term-debug">
- <title>Debugging your 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
- symptoms and some suggested fixes.</para>
-
- <variablelist>
- <varlistentry>
- <term>No login prompt appears</term>
-
- <listitem>
- <para>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 FreeBSD computer. Make sure it is the right kind of
- cable.</para>
-
- <para>Make sure the terminal and FreeBSD agree on the bps rate and
- parity settings. If you have 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>Make sure that a <command>getty</command> process is running
- and serving the terminal. Type <screen>&prompt.root;
- <userinput>ps -axww|grep getty</userinput></screen> to get a
- list of running <command>getty</command> processes. You should
- see an entry for the terminal. For example, the display
-
- <screen>22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1</screen>
-
- shows that a <command>getty</command> is running on the second
- serial port <literal>ttyd1</literal> and is using the
- <literal>std.38400</literal> entry in
- <filename>/etc/gettytab</filename>.</para>
-
- <para>If no <command>getty</command> process is running, make sure
- you have enabled the port in <filename>/etc/ttys</filename>.
- Make sure you have run <command>kill -HUP 1</command>.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Garbage appears instead of a login prompt</term>
-
- <listitem>
- <para>Make sure the terminal and FreeBSD agree on the bps rate and
- parity settings. Check the getty 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>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Characters appear doubled; the password appears when
- typed</term>
-
- <listitem>
- <para>Switch the terminal (or the terminal emulation software)
- from <quote>half duplex</quote> or <quote>local echo</quote> to
- <quote>full duplex.</quote></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- </sect1>
-
- <sect1 id="dialup">
- <title>Dial-in Service</title>
-
- <para><emphasis>Contributed by &a.ghelmer;.</emphasis></para>
-
- <para>This document provides suggestions for configuring a FreeBSD system
- to handle dial-up modems. This document is written based on the author's
- experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience
- with dial-up modems on other UNIX-like operating systems); however, this
- document may not answer all of your questions or provide examples
- specific enough to your environment. The author cannot be responsible if
- you damage your system or lose data due to attempting to follow the
- suggestions here.</para>
-
- <sect2 id="dialup-prereqs">
- <title>Prerequisites</title>
-
- <para>To begin with, the author assumes you have some basic knowledge of
- FreeBSD. You need to have FreeBSD installed, know how to edit files
- in a UNIX-like environment, and how to look up manual pages on the
- system. As discussed below, you will need certain versions of
- FreeBSD, and knowledge of some terminology &amp; modem and
- cabling.</para>
-
- <sect3>
- <title>FreeBSD Version</title>
-
- <para>First, it is assumed that you are using FreeBSD version 1.1 or
- higher (including versions 2.x). FreeBSD version 1.0 included two
- different serial drivers, which complicates the situation. Also,
- the serial device driver (<devicename>sio</devicename>) has improved
- in every release of FreeBSD, so more recent versions of FreeBSD are
- assumed to have better and more efficient drivers than earlier
- versions.</para>
- </sect3>
-
- <sect3>
- <title>Terminology</title>
-
- <para>A quick rundown of terminology:</para>
-
- <variablelist>
- <varlistentry>
- <term>bps</term>
-
- <listitem>
- <para>Bits per Second &mdash; the rate at which data is
- transmitted</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>DTE</term>
-
- <listitem>
- <para>Data Terminal Equipment &mdash; for example, your
- computer</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>DCE</term>
-
- <listitem>
- <para>Data Communications Equipment &mdash; your modem</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>RS-232</term>
-
- <listitem>
- <para>EIA standard for serial communications via hardware</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>If you need more information about these terms and data
- communications in general, the author remembers reading that
- <emphasis>The RS-232 Bible</emphasis> (anybody have an ISBN?) is a
- good reference.</para>
-
- <para>When talking about communications data rates, the author does
- not use the term <quote>baud</quote>. Baud refers to the number of
- electrical state transitions that may be made in a period of time,
- while <quote>bps</quote> (bits per second) is the
- <quote>correct</quote> term to use (at least it does not seem to
- bother the curmudgeons quite a much).</para>
- </sect3>
-
- <sect3>
- <title>External v.s. Internal Modems</title>
-
- <para>External modems seem to be more convenient for dial-up, because
- external modems often can be semi-permanently configured via
- parameters stored in non-volatile RAM and they usually provide
- lighted indicators that display the state of important RS-232
- signals. Blinking lights impress visitors, but lights are also very
- useful to see whether a modem is operating properly.</para>
-
- <para>Internal modems usually lack non-volatile RAM, so their
- configuration may be limited only to setting DIP switches. If your
- internal modem has any signal indicator lights, it is probably
- difficult to view the lights when the system's cover is in
- place.</para>
- </sect3>
-
- <sect3>
- <title>Modems and Cables</title>
-
- <para>A background knowledge of these items is assumed</para>
-
- <itemizedlist>
- <listitem>
- <para>You know how to connect your modem to your computer so that
- the two can communicate (unless you have an internal modem,
- which does not need such a cable)</para>
- </listitem>
-
- <listitem>
- <para>You are familiar with your modem's command set, or know
- where to look up needed commands</para>
- </listitem>
-
- <listitem>
- <para>You know how to configure your modem (probably via a
- terminal communications program) so you can set the non-volatile
- RAM parameters</para>
- </listitem>
- </itemizedlist>
-
- <para>The first, connecting your modem, is usually simple &mdash; most
- straight-through serial cables work without any problems. You need
- to have a cable with appropriate connectors (DB-25 or DB-9, male or
- female) on each end, and the cable must be a DCE-to-DTE cable with
- these signals wired:</para>
-
- <itemizedlist>
- <listitem>
- <para>Transmitted Data (<acronym>SD</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Received Data (<acronym>RD</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Request to Send (<acronym>RTS</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Clear to Send (<acronym>CTS</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Data Set Ready (<acronym>DSR</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Data Terminal Ready (<acronym>DTR</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Carrier Detect (<acronym>CD</acronym>)</para>
- </listitem>
-
- <listitem>
- <para>Signal Ground (<acronym>SG</acronym>)</para>
- </listitem>
- </itemizedlist>
-
- <para>FreeBSD needs the <acronym>RTS</acronym> and
- <acronym>CTS</acronym> signals for flow-control at speeds above
- 2400bps, 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 you have problems, such as a login session not going away when
- the line hangs up, you may have a problem with your cable.</para>
-
- <para>The second prerequisite depends on the modem(s) you use. If you
- do not know your modem's command set by heart, you will need to have
- the modem's reference book or user's guide handy. Sample commands
- for USR Sportster 14,400 external modems will be given, which you
- may be able to use as a reference for your own modem's
- commands.</para>
-
- <para>Lastly, you will need to know how to setup your modem so that it
- will work well with FreeBSD. Like other UNIX-like operating
- systems, FreeBSD 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. FreeBSD avoids sending commands to the
- modem or watching for status reports from the modem. If you are
- familiar with connecting modems to PC-based bulletin board systems,
- this may seem awkward.</para>
- </sect3>
-
- <sect3>
- <title>Serial Interface Considerations</title>
-
- <para>FreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based
- EIA RS-232C (CCITT 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's prevent the use of the
- 16-character buffer, so use 16550A's 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 much 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>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Quick Overview</title>
-
- <para>Here is the process that FreeBSD follows to accept dial-up logins.
- A <command>getty</command> process, spawned by
- <command>init</command>, patiently waits to open the assigned serial
- port (<filename>/dev/ttyd0</filename>, for our example). The command
- <command>ps ax</command> might show this:</para>
-
- <screen> 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0</screen>
-
- <para>When a user dials the modem's line and the modems connect, the
- <acronym>CD</acronym> line is asserted by the modem. The kernel
- notices that carrier has been detected and completes
- <command>getty</command>'s open of the port. <command>getty</command>
- sends a <prompt>login:</prompt> prompt at the specified initial line
- speed. <command>getty</command> watches to see if legitimate
- characters are received, and, in a typical configuration, if it finds
- junk (probably due to the modem's connection speed being different
- than <command>getty</command>'s speed), <command>getty</command> tries
- adjusting the line speeds until it receives reasonable
- characters.</para>
-
- <para>We hope <command>getty</command> finds the correct speed and the
- user sees a <prompt>login:</prompt> prompt. After the user enters
- his/her login name, <command>getty</command> executes
- <filename>/usr/bin/login</filename>, which completes the login by
- asking for the user's password and then starting the user's
- shell.</para>
-
- <para>Let's dive into the configuration...</para>
- </sect2>
-
- <sect2>
- <title>Kernel Configuration</title>
-
- <para>FreeBSD kernels typically come prepared to search for four serial
- ports, known in the PC-DOS world as <devicename>COM1:</devicename>,
- <devicename>COM2:</devicename>, <devicename>COM3:</devicename>, and
- <devicename>COM4:</devicename>. FreeBSD can presently also handle
- <quote>dumb</quote> multiport serial interface cards, such as the Boca
- Board 1008 and 2016 (please see the manual page &man.sio.4; for kernel
- configuration information if you have a multiport serial card). The
- default kernel only looks for the standard COM ports, though.</para>
-
- <para>To see if your kernel recognizes any of your serial ports, watch
- for messages while the kernel is booting, or use the
- <command>/sbin/dmesg</command> command to replay the kernel's boot
- messages. In particular, look for messages that start with the
- characters <literal>sio</literal>. Hint: to view just the messages
- that have the word <literal>sio</literal>, use the command:</para>
-
- <screen>&prompt.root; <userinput>/sbin/dmesg | grep 'sio'</userinput></screen>
-
- <para>For example, on a system with four serial ports, these are the
- serial-port specific kernel boot messages:</para>
-
- <screen>sio0 at 0x3f8-0x3ff irq 4 on isa
-sio0: type 16550A
-sio1 at 0x2f8-0x2ff irq 3 on isa
-sio1: type 16550A
-sio2 at 0x3e8-0x3ef irq 5 on isa
-sio2: type 16550A
-sio3 at 0x2e8-0x2ef irq 9 on isa
-sio3: type 16550A</screen>
-
- <para>If your kernel does not recognize all of your serial ports, you
- will probably need to configure a custom FreeBSD kernel for your
- system.</para>
-
- <para>Please see the BSD System Manager's Manual chapter on
- <quote>Building Berkeley Kernels with Config</quote> [the source for
- which is in <filename>/usr/src/share/doc/smm</filename>] and
- <quote>FreeBSD Configuration Options</quote> [in
- <filename>/sys/conf/options</filename> and in
- <filename>/sys/<replaceable>arch</replaceable>/conf/options.<replaceable>arch</replaceable></filename>,
- with <emphasis>arch</emphasis> for example being
- <filename>i386</filename>] for more information on configuring and
- building kernels. You may have to unpack the kernel source
- distribution if have not installed the system sources already
- (<filename>srcdist/srcsys.??</filename> in FreeBSD 1.1,
- <filename>srcdist/sys.??</filename> in FreeBSD 1.1.5.1, or the entire
- source distribution in FreeBSD 2.0) to be able to configure and build
- kernels.</para>
-
- <para>Create a kernel configuration file for your system (if you have
- not already) by <command>cd</command>ing to
- <filename>/sys/i386/conf</filename>. Then, if you are creating a new
- custom configuration file, copy the file
- <filename>GENERICAH</filename> (or <filename>GENERICBT</filename>, if
- you have a BusTek SCSI controller on FreeBSD 1.x) to
- <filename>YOURSYS</filename>, where <filename>YOURSYS</filename> is
- the name of your system, but in upper-case letters. Edit the file,
- and change the device lines:</para>
-
- <programlisting>
-device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
-device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
-device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
-device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr</programlisting>
-
- <para>You can comment-out or completely remove lines for devices you do
- not have. If you have a multiport serial board, such as the Boca
- Board BB2016, please see the &man.sio.4; man page for complete
- information on how to write configuration lines for multiport boards.
- Be careful if you are using a configuration file that was previously
- used for a different version of FreeBSD because the device flags have
- changed between versions.</para>
-
- <note>
- <para><literal>port "IO_COM1"</literal> is a substitution for
- <literal>port 0x3f8</literal>, <literal>IO_COM2</literal> is
- <literal>0x2f8</literal>, <literal>IO_COM3</literal> is
- <literal>0x3e8</literal>, and <literal>IO_COM4</literal> is
- <literal>0x2e8</literal>, which are fairly common port addresses for
- their respective serial ports; interrupts 4, 3, 5, and 9 are fairly
- common interrupt request lines. Also note that regular serial ports
- <emphasis>cannot</emphasis> share interrupts on ISA-bus PCs
- (multiport boards have on-board electronics that allow all the
- 16550A's on the board to share one or two interrupt request
- lines).</para>
- </note>
-
- <para>When you are finished adjusting the kernel configuration file, use
- the program <command>config</command> as documented in <quote>Building
- Berkeley Kernels with Config</quote> and the
- &man.config.8; manual page to prepare a kernel building directory,
- then build, install, and test the new kernel.</para>
- </sect2>
-
- <sect2>
- <title>Device Special Files</title>
-
- <para>Most devices in the kernel are accessed through <quote>device
- special files</quote>, which are located in the
- <filename>/dev</filename> directory. The <devicename>sio</devicename>
- devices are accessed through the
- <filename>/dev/ttyd<replaceable>?</replaceable></filename> (dial-in)
- and <filename>/dev/cua0<replaceable>?</replaceable></filename>
- (call-out) devices. On FreeBSD version 1.1.5 and higher, there are
- also initialization devices
- (<filename>/dev/ttyid<replaceable>?</replaceable></filename> and
- <filename>/dev/cuai0<replaceable>?</replaceable></filename>) and
- locking devices
- (<filename>/dev/ttyld<replaceable>?</replaceable></filename> and
- <filename>/dev/cual0<replaceable>?</replaceable></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>CTS/RTS</literal> signaling for flow control. The locking
- devices are used to lock flags on ports to prevent users or programs
- changing certain parameters; see the manual pages &man.termios.4;,
- &man.sio.4;, and &man.stty.1; for
- information on the terminal settings, locking &amp; initializing
- devices, and setting terminal options, respectively.</para>
-
- <sect3>
- <title>Making Device Special Files</title>
-
- <para>A shell script called <command>MAKEDEV</command> in the
- <filename>/dev</filename> directory manages the device special
- files. (The manual page for &man.MAKEDEV.8; on FreeBSD 1.1.5 is
- fairly bogus in its discussion of <acronym>COM</acronym> ports, so
- ignore it.) To use <command>MAKEDEV</command> to make dial-up device
- special files for <devicename>COM1:</devicename> (port 0),
- <command>cd</command> to <filename>/dev</filename> and issue the
- command <command>MAKEDEV ttyd0</command>. Likewise, to make dial-up
- device special files for <devicename>COM2:</devicename> (port 1),
- use <command>MAKEDEV ttyd1</command>.</para>
-
- <para><command>MAKEDEV</command> not only creates the
- <filename>/dev/ttyd<replaceable>?</replaceable></filename> device
- special files, but also creates the
- <filename>/dev/cua0<replaceable>?</replaceable></filename> (and all
- of the initializing and locking special files under FreeBSD 1.1.5
- and up) and removes the hardwired terminal special file
- <filename>/dev/tty0<replaceable>?</replaceable></filename>, if it
- exists.</para>
-
- <para>After making new device special files, be sure to check the
- permissions on the files (especially the
- <filename>/dev/cua*</filename> files) to make sure that only users
- who should have access to those device special files can read &amp;
- write on them &mdash; you probably do not want to allow your average
- user to use your modems to dial-out. The default permissions on the
- <filename>/dev/cua*</filename> files should be sufficient:</para>
-
- <screen>crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01
-crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01
-crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01</screen>
-
- <para>These permissions allow the user <username>uucp</username> and
- users in the group <username>dialer</username> to use the call-out
- devices.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Configuration Files</title>
-
- <para>There are three system configuration files in the
- <filename>/etc</filename> directory that you will probably need to
- edit to allow dial-up access to your FreeBSD system. The first,
- <filename>/etc/gettytab</filename>, contains configuration information
- for the <filename>/usr/libexec/getty</filename> daemon. Second,
- <filename>/etc/ttys</filename> holds information that tells
- <filename>/sbin/init</filename> what <filename>tty</filename> devices
- should have <command>getty</command> processes running on them.
- Lastly, you can place port initialization commands in the
- <filename>/etc/rc.serial</filename> script if you have FreeBSD 1.1.5.1
- or higher; otherwise, you can initialize ports in the
- <filename>/etc/rc.local</filename> script.</para>
-
- <para>There are two schools of thought regarding dial-up modems on UNIX.
- One group likes to configure their modems and system so that no matter
- at what speed a remote user dials in, the local computer-to-modem
- RS-232 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 Emacs
- will not adjust their screen-painting methods to make their response
- better for slower connections.</para>
-
- <para>The other school configures their modems' RS-232 interface to vary
- its speed based on the remote user's connection speed. For example,
- V.32bis (14.4 Kbps) connections to the modem might make the modem run
- its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
- modem's RS-232 interface run at 2400 bps. Because
- <command>getty</command> does not understand any particular modem's
- connection speed reporting, <command>getty</command> gives a
- <prompt>login:</prompt> message at an initial speed and watches the
- characters that come back in response. If the user sees junk, it is
- assumed that they know they should press the
- <literal>&lt;Enter&gt;</literal> key until they see a recognizable
- prompt. If the data rates do not match, <command>getty</command> sees
- anything the user types as <quote>junk</quote>, tries going to the next
- speed and gives the <prompt>login:</prompt> prompt again. This
- procedure can continue ad nauseum, but normally only takes a keystroke
- or two before the user sees a good prompt. Obviously, this login
- sequence does not look as clean as the former
- <quote>locked-speed</quote> method, but a user on a low-speed
- connection should receive better interactive response from full-screen
- programs.</para>
-
- <para>The author will try to give balanced configuration information,
- but is biased towards having the modem's data rate follow the
- connection rate.</para>
-
- <sect3>
- <title><filename>/etc/gettytab</filename></title>
-
- <para><filename>/etc/gettytab</filename> is a &man.termcap.5;-style
- file of configuration information for &man.getty.8;. Please see the
- &man.gettytab.5; manual page for complete information on the
- format of the file and the list of capabilities.</para>
-
- <sect4>
- <title>Locked-Speed Config</title>
-
- <para>If you are locking your modem's data communications rate at a
- particular speed, you probably will not need to make any changes
- to <filename>/etc/gettytab</filename>.</para>
- </sect4>
-
- <sect4>
- <title>Matching-Speed Config</title>
-
- <para>You will need to setup an entry in
- <filename>/etc/gettytab</filename> to give
- <command>getty</command> information about the speeds you wish to
- use for your modem. If you have a 2400 bps modem, you can
- probably use the existing <literal>D2400</literal> entry. This
- entry already exists in the FreeBSD 1.1.5.1
- <filename>gettytab</filename> file, so you do not need to add it
- unless it is missing under your version of FreeBSD:</para>
-
- <programlisting>
-#
-# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
-#
-D2400|d2400|Fast-Dial-2400:\
- :nx=D1200:tc=2400-baud:
-3|D1200|Fast-Dial-1200:\
- :nx=D300:tc=1200-baud:
-5|D300|Fast-Dial-300:\
- :nx=D2400:tc=300-baud:</programlisting>
-
- <para>If you have a higher speed modem, you will probably need to
- add an entry in <filename>/etc/gettytab</filename>; here is an
- entry you could use for a 14.4 Kbps modem with a top interface
- speed of 19.2 Kbps:</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>On FreeBSD 1.1.5 and later, this will result in 8-bit, no
- parity connections. Under FreeBSD 1.1, add
- <literal>:np:</literal> parameters to the
- <literal>std.<replaceable>xxx</replaceable></literal> entries at
- the top of the file for 8 bits, no parity; otherwise, the default
- is 7 bits, even parity.</para>
-
- <para>The example above starts the communications rate at 19.2 Kbps
- (for a V.32bis connection), then cycles through 9600 bps (for
- V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps.
- Communications rate cycling is implemented with the
- <literal>nx=</literal> (<quote>next table</quote>) capability.
- Each of the lines uses a <literal>tc=</literal> (<quote>table
- continuation</quote>) entry to pick up the rest of the
- <quote>standard</quote> settings for a particular data rate.</para>
-
- <para>If you have a 28.8 Kbps modem and/or you want to take
- advantage of compression on a 14.4 Kbps modem, you need to use a
- higher communications rate than 19.2 Kbps. Here is an example of
- a <filename>gettytab</filename> entry starting a 57.6 Kbps:</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>If you have a slow CPU or a heavily loaded system and you do
- not have 16550A-based serial ports, you may receive sio
- <quote>silo</quote> errors at 57.6 Kbps.</para>
- </sect4>
- </sect3>
-
- <sect3 id="dialup-ttys">
- <title><filename>/etc/ttys</filename></title>
-
- <para><filename>/etc/ttys</filename> is the list of
- <filename>ttys</filename> for <command>init</command> to monitor.
- <filename>/etc/ttys</filename> also provides security information to
- <command>login</command> (user <username>root</username> may only
- login on ttys marked <literal>secure</literal>). See the manual
- page for
- &man.ttys.5; for more information.</para>
-
- <para>You will need to either modify existing lines in
- <filename>/etc/ttys</filename> or add new lines to make
- <command>init</command> run <command>getty</command> processes
- automatically on your new dial-up ports. The general format of the
- line will be the same, whether you are using a locked-speed or
- matching-speed configuration:</para>
-
- <programlisting>
-ttyd0 "/usr/libexec/getty xxx" dialup on</programlisting>
-
- <para>The first item in the above line is the device special file for
- this entry &mdash; <literal>ttyd0</literal> means
- <filename>/dev/ttyd0</filename> is the file that this
- <command>getty</command> will be watching. The second item,
- <literal>"/usr/libexec/getty
- <replaceable>xxx</replaceable>"</literal>
- (<replaceable>xxx</replaceable> will be replaced by the initial
- <filename>gettytab</filename> capability) is the process
- <command>init</command> will run on the device. The third item,
- <literal>dialup</literal>, is the default terminal type. The fourth
- parameter, <literal>on</literal>, indicates to
- <command>init</command> that the line is operational. There can be
- a fifth parameter, <literal>secure</literal>, but it should only be
- used for terminals which are physically secure (such as the system
- console).</para>
-
- <para>The default terminal type (<literal>dialup</literal> in the
- example above) may depend on local preferences.
- <literal>dialup</literal> is the traditional default terminal type
- on dial-up lines so that users may customize their login scripts to
- notice when the terminal is <literal>dialup</literal> and
- automatically adjust their terminal type. However, the author finds
- it easier at his site to specify <literal>vt102</literal> as the
- default terminal type, since the users just use VT102 emulation on
- their remote systems.</para>
-
- <para>After you have made changes to <filename>/etc/ttys</filename>,
- you may send the <command>init</command> process a
- <acronym>HUP</acronym> signal to re-read the file. You can use the
- command <screen>&prompt.root; <userinput>kill -1
- 1</userinput></screen> to send the signal. If this is your
- first time setting up the system, though, you may want to wait until
- your modem(s) are properly configured and connected before signaling
- <command>init</command>.</para>
-
- <sect4>
- <title>Locked-Speed Config</title>
-
- <para>For a locked-speed configuration, your
- <filename>ttys</filename> entry needs to have a fixed-speed entry
- provided to <command>getty</command>. For a modem whose port
- speed is locked at 19.2 Kbps, the <filename>ttys</filename> entry
- might look like this:</para>
-
- <programlisting>
-ttyd0 "/usr/libexec/getty std.19200" dialup on</programlisting>
-
- <para>If your modem is locked at a different data rate, substitute
- the appropriate name for the
- <literal>std.<replaceable>speed</replaceable></literal> entry for
- <literal>std.19200</literal> from
- <filename>/etc/gettytab</filename> for your modem's data
- rate.</para>
- </sect4>
-
- <sect4>
- <title>Matching-Speed Config</title>
-
- <para>In a matching-speed configuration, your
- <filename>ttys</filename> entry needs to reference the appropriate
- beginning <quote>auto-baud</quote> (sic) entry in
- <filename>/etc/gettytab</filename>. For example, if you added the
- above suggested entry for a matching-speed modem that starts at
- 19.2 Kbps (the <filename>gettytab</filename> entry containing the
- <literal>V19200</literal> starting point), your
- <filename>ttys</filename> entry might look like this:</para>
-
- <programlisting>
-ttyd0 "/usr/libexec/getty V19200" dialup on</programlisting>
- </sect4>
- </sect3>
-
- <sect3>
- <title><filename>/etc/rc.serial</filename> or
- <filename>/etc/rc.local</filename></title>
-
- <para>High-speed modems, like V.32, V.32bis, and V.34 modems, need to
- use hardware (<filename>RTS/CTS</filename>) flow control. You can
- add <command>stty</command> commands to
- <filename>/etc/rc.serial</filename> on FreeBSD 1.1.5.1 and up, or
- <filename>/etc/rc.local</filename> on FreeBSD 1.1, to set the
- hardware flow control flag in the FreeBSD kernel for the modem
- ports.</para>
-
- <para>For example, on a sample FreeBSD 1.1.5.1 system,
- <filename>/etc/rc.serial</filename> reads:</para>
-
- <programlisting>
-#!/bin/sh
-#
-# Serial port initial configuration
-
-stty -f /dev/ttyid1 crtscts
-stty -f /dev/cuai01 crtscts</programlisting>
-
- <para>This sets the <literal>termios</literal> flag
- <literal>crtscts</literal> on serial port #1's
- (<devicename>COM2:</devicename>) dial-in and dial-out initialization
- devices.</para>
-
- <para>On an old FreeBSD 1.1 system, these entries were added to
- <filename>/etc/rc.local</filename> to set the
- <literal>crtscts</literal> flag on the devices:</para>
-
- <programlisting>
-# Set serial ports to use RTS/CTS flow control
-stty -f /dev/ttyd0 crtscts
-stty -f /dev/ttyd1 crtscts
-stty -f /dev/ttyd2 crtscts
-stty -f /dev/ttyd3 crtscts</programlisting>
-
- <para>Since there is no initialization device special file on FreeBSD
- 1.1, one has to just set the flags on the sole device special file
- and hope the flags are not cleared by a miscreant.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Modem Settings</title>
-
- <para>If you have a modem whose parameters may be permanently set in
- non-volatile RAM, you will need to use a terminal program (such as
- Telix under PC-DOS or <command>tip</command> under FreeBSD) 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; dropping DTR
- hangs up line &amp; resets 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>Please read the documentation for your modem to find out what
- commands and/or DIP switch settings you need to give it.</para>
-
- <para>For example, to set the above parameters on a USRobotics
- Sportster 14,400 external modem, one could give these commands to
- the modem:</para>
-
- <programlisting>
-ATZ
-AT&amp;C1&amp;D2&amp;H1&amp;I0&amp;R2&amp;W</programlisting>
-
- <para>You might also want to take this opportunity to adjust other
- settings in the modem, such as whether it will use V.42bis and/or MNP5
- compression.</para>
-
- <para>The USR Sportster 14,400 external modem also has some DIP switches
- that need to be set; for other modems, perhaps you can use these
- settings as an example:</para>
-
- <itemizedlist>
- <listitem>
- <para>Switch 1: UP &mdash; DTR Normal</para>
- </listitem>
-
- <listitem>
- <para>Switch 2: Do not care (Verbal Result Codes/Numeric Result
- Codes)</para>
- </listitem>
-
- <listitem>
- <para>Switch 3: UP &mdash; Suppress Result Codes</para>
- </listitem>
-
- <listitem>
- <para>Switch 4: DOWN &mdash; No echo, offline commands</para>
- </listitem>
-
- <listitem>
- <para>Switch 5: UP &mdash; Auto Answer</para>
- </listitem>
-
- <listitem>
- <para>Switch 6: UP &mdash; Carrier Detect Normal</para>
- </listitem>
-
- <listitem>
- <para>Switch 7: UP &mdash; Load NVRAM Defaults</para>
- </listitem>
-
- <listitem>
- <para>Switch 8: Do not care (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. I
- have heard this sequence can result in a extended, silly conversation
- between <command>getty</command> and the modem.</para>
-
- <sect3>
- <title>Locked-speed Config</title>
-
- <para>For a locked-speed configuration, you will need to configure the
- modem to maintain a constant modem-to-computer data rate independent
- of the communications rate. On a USR 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&amp;B1&amp;W</programlisting>
- </sect3>
-
- <sect3>
- <title>Matching-speed Config</title>
-
- <para>For a variable-speed configuration, you will need to configure
- your modem to adjust its serial port data rate to match the incoming
- call rate. On a USR Sportster 14,400 external modem, these commands
- will lock the modem's error-corrected data rate to the speed used to
- issue the commands, but allow the serial port rate to vary for
- non-error-corrected connections:</para>
-
- <programlisting>
-ATZ
-AT&amp;B2&amp;W</programlisting>
- </sect3>
-
- <sect3>
- <title>Checking the Modem's Configuration</title>
-
- <para>Most high-speed modems provide commands to view the modem's
- current operating parameters in a somewhat human-readable fashion.
- On the USR Sportster 14,400 external modems, the command
- <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 USR's DIP switch settings), use the commands
- <command>ATZ</command> and then <command>ATI4</command>.</para>
-
- <para>If you have a different brand of modem, check your modem's
- manual to see how to double-check your modem's configuration
- parameters.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Troubleshooting</title>
-
- <para>Here are a few steps you can follow to check out the dial-up modem
- on your system.</para>
-
- <sect3>
- <title>Checking out the FreeBSD system</title>
-
- <para>Hook up your modem to your FreeBSD system, boot the system, and,
- if your 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
- &mdash; if it lights up, that should mean that FreeBSD 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 doesn't light, login to
- the FreeBSD system through the console and issue a <command>ps
- ax</command> to see if FreeBSD is trying to run a
- <command>getty</command> process on the correct port. You should see
- a lines like this among the processes displayed:</para>
-
- <screen> 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
- 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1</screen>
-
- <para>If you see something different, like this:</para>
-
- <screen> 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0</screen>
-
- <para>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 mis-configured modem, because <command>getty</command> should
- not be able to open the communications port until
- <acronym>CD</acronym> (carrier detect) has been asserted by the
- modem.</para>
-
- <para>If you do not see any <command>getty</command> processes waiting
- to open the desired
- <filename>ttyd<replaceable>?</replaceable></filename> port,
- double-check your entries in <filename>/etc/ttys</filename> to see
- if there are any mistakes there. Also, check the log file
- <filename>/var/log/messages</filename> to see if there are any log
- messages from <command>init</command> or <command>getty</command>
- regarding any problems. If there are any messages, triple-check the
- configuration files <filename>/etc/ttys</filename> and
- <filename>/etc/gettytab</filename>, as well as the appropriate
- device special files <filename>/dev/ttyd?</filename>, for any
- mistakes, missing entries, or missing device special files.</para>
- </sect3>
-
- <sect3>
- <title>Try Dialing In</title>
-
- <para>Try dialing into the system; be sure to use 8 bits, no parity, 1
- stop bit on the remote system. If you do not get a prompt right
- away, or get garbage, try pressing <literal>&lt;Enter&gt;</literal>
- about once per second. If you still do not see a
- <prompt>login:</prompt> prompt after a while, try sending a
- <command>BREAK</command>. If you are using a high-speed modem to do
- the dialing, try dialing again after locking the dialing modem's
- interface speed (via <command>AT&amp;B1</command> on a USR
- Sportster, for example).</para>
-
- <para>If you still cannot get a <prompt>login:</prompt> prompt, check
- <filename>/etc/gettytab</filename> again and double-check
- that</para>
-
- <itemizedlist>
- <listitem>
- <para>The initial capability name specified in
- <filename>/etc/ttys</filename> for the line matches a 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 you dial but the modem on the FreeBSD 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 (if it has
- any).</para>
-
- <para>If you have gone over everything several times and it still does
- not work, take a break and come back to it later. If it still does
- not work, perhaps you can send an electronic mail message to the
- &a.questions;describing your modem and your problem, and the good
- folks on the list will try to help.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Acknowledgments</title>
-
- <para>Thanks to these people for comments and advice:</para>
-
- <variablelist>
- <varlistentry>
- <term>&a.kelly;</term>
-
- <listitem>
- <para>for a number of good suggestions</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- </sect1>
-
- <sect1 id="dialout">
- <title>Dial-out Service</title>
-
- <para><emphasis>Information integrated from FAQ.</emphasis></para>
-
- <para>The following are tips to getting your host to be able to connect
- over the modem to another computer. This is appropriate for
- establishing a terminal session with a remote host.</para>
-
- <para>This is useful to log onto a BBS.</para>
-
- <para>This kind of connection can be extremely helpful to get a file on
- the Internet if you have problems with PPP. If you need to FTP
- something and PPP is broken, use the terminal session to FTP it. Then
- use zmodem to transfer it to your machine.</para>
-
- <sect2>
- <title>Why cannot I run <command>tip</command> or
- <command>cu</command>?</title>
-
- <para>On your system, the programs <command>tip</command> and
- <command>cu</command> are probably executable only by
- <username>uucp</username> and group <username>dialer</username>. You
- can use the group <username>dialer</username> to control who has
- access to your modem or remote systems. Just add yourself to group
- dialer.</para>
-
- <para>Alternatively, you can let everyone on your system run
- <command>tip</command> and <command>cu</command> by typing:</para>
-
- <screen>&prompt.root; <userinput>chmod 4511 /usr/bin/tip</userinput></screen>
-
- <para>You do not have to run this command for <command>cu</command>,
- since <command>cu</command> is just a hard link to
- <command>tip</command>.</para>
- </sect2>
-
- <sect2>
- <title>My stock Hayes modem is not supported, what can I do?</title>
-
- <para>Actually, the man page for <command>tip</command> is out of date.
- There is a generic Hayes dialer already built in. Just use
- <literal>at=hayes</literal> in your <filename>/etc/remote</filename>
- file.</para>
-
- <para>The Hayes driver is not smart enough to recognize some of the
- advanced features of newer modems&mdash;messages like
- <literal>BUSY</literal>, <literal>NO DIALTONE</literal>, or
- <literal>CONNECT 115200</literal> will just confuse it. You should
- turn those messages off when you use <command>tip</command> (using
- <command>ATX0&amp;W</command>).</para>
-
- <para>Also, the dial timeout for <command>tip</command> is 60 seconds.
- Your modem should use something less, or else tip will think there is
- a communication problem. Try <command>ATS7=45&amp;W</command>.</para>
-
- <para>Actually, as shipped <command>tip</command> does not yet support
- it fully. The solution is to edit the file
- <filename>tipconf.h</filename> in the directory
- <filename>/usr/src/usr.bin/tip/tip</filename> Obviously you need the
- source distribution to do this.</para>
-
- <para>Edit the line <literal>#define HAYES 0</literal> to
- <literal>#define HAYES 1</literal>. Then <command>make</command> and
- <command>make install</command>. Everything works nicely after
- that.</para>
- </sect2>
-
- <sect2 id="direct-at">
- <title>How am I expected to enter these AT commands?</title>
-
- <para>Make what is called a <quote>direct</quote> entry in your
- <filename>/etc/remote</filename> file. For example, if your modem is
- hooked up to the first serial port, <filename>/dev/cuaa0</filename>,
- then put in the following line:</para>
-
- <programlisting>
-cuaa0:dv=/dev/cuaa0:br#19200:pa=none</programlisting>
-
- <para>Use the highest bps rate your modem supports in the br capability.
- Then, type <command>tip cuaa0</command> and you will be connected to
- your modem.</para>
-
- <para>If there is no <filename>/dev/cuaa0</filename> on your system, do
- this:</para>
-
- <screen>&prompt.root; <userinput>cd /dev</userinput>
-&prompt.root; <userinput>MAKEDEV cuaa0</userinput></screen>
-
- <para>Or use cu as root 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
- (e.g.<filename>/dev/cuaa0</filename>) and
- <replaceable>speed</replaceable> is the speed
- (e.g.<literal>57600</literal>). When you are done entering the AT
- commands hit <command>~.</command> to exit.</para>
- </sect2>
-
- <sect2>
- <title>The <literal>@</literal> sign for the pn capability does not
- work!</title>
-
- <para>The <literal>@</literal> sign in the phone number capability tells
- tip 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>. Escape it
- with a backslash:</para>
-
- <programlisting>
-pn=\@</programlisting>
- </sect2>
-
- <sect2>
- <title>How can I dial a phone number on the command line?</title>
-
- <para>Put what is called a <quote>generic</quote> entry in your
- <filename>/etc/remote</filename> file. For example:</para>
-
- <programlisting>
-tip115200|Dial any phone number at 115200 bps:\
- :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
-tip57600|Dial any phone number at 57600 bps:\
- :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:</programlisting>
-
- <para>Then you can things like:</para>
-
- <screen>&prompt.root; <userinput>tip -115200 5551234</userinput></screen>
-
- <para>If you prefer <command>cu</command> over <command>tip</command>,
- use a generic cu entry:</para>
-
- <programlisting>
-cu115200|Use cu to dial any number at 115200bps:\
- :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:</programlisting>
-
- <para>and type:</para>
-
- <screen>&prompt.root; <userinput>cu 5551234 -s 115200</userinput></screen>
- </sect2>
-
- <sect2>
- <title>Do I have to type in the bps rate every time I do that?</title>
-
- <para>Put in an entry for <literal>tip1200</literal> or
- <literal>cu1200</literal>, but go ahead and use whatever bps rate is
- appropriate with the br capability. <command>tip</command> thinks a
- good default is 1200 bps which is why it looks for a
- <literal>tip1200</literal> entry. You do not have to use 1200 bps,
- though.</para>
- </sect2>
-
- <sect2>
- <title>I access a number of hosts through a terminal server.</title>
-
- <para>Rather than waiting until you are connected and typing
- <command>CONNECT &lt;host&gt;</command> each time, use tip's
- <literal>cm</literal> capability. For example, these entries in
- <filename>/etc/remote</filename>:</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/cua02:br#38400:at=hayes:du:pa=none:pn=5551234:</programlisting>
-
- <para>will let you type <command>tip pain</command> or <command>tip
- muffin</command> to connect to the hosts pain or muffin; and
- <command>tip deep13</command> to get to the terminal server.</para>
- </sect2>
-
- <sect2>
- <title>Can tip try more than one line for each site?</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 for your university 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/cuaa3:br#9600:at=courier:du:pa=none:</programlisting>
-
- <para>Then, list the phone numbers for the university 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 one in the listed order, then
- give up. If you want to keep retrying, run <command>tip</command> in
- a while loop.</para>
- </sect2>
-
- <sect2>
- <title>Why do I have to hit CTRL+P twice to send CTRL+P once?</title>
-
- <para>CTRL+P is the default <quote>force</quote> character, used to tell
- <command>tip</command> that the next character is literal data. You
- can set the force character 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 you leave out
- <replaceable>single-char</replaceable>, then the force character is
- the nul character, which you can get by typing CTRL+2 or CTRL+SPACE.
- A pretty good value for <replaceable>single-char</replaceable> is
- SHIFT+CTRL+6, which I have seen only used on some terminal
- servers.</para>
-
- <para>You can have the force character be whatever you want by
- specifying the following in your <filename>&#36;HOME/.tiprc</filename>
- file:</para>
-
- <programlisting>
-force=&lt;single-char&gt;</programlisting>
- </sect2>
-
- <sect2>
- <title>Suddenly everything I type is in UPPER CASE??</title>
-
- <para>You must have pressed CTRL+A, <command>tip</command>'s
- <quote>raise character,</quote> specially designed for people with
- broken caps-lock keys. Use <command>~s</command> as above and set the
- variable <literal>raisechar</literal> to something reasonable. In
- fact, you can set it to the same as the force character, if you never
- expect to use either of these features.</para>
-
- <para>Here is a sample .tiprc file perfect for Emacs users who need to
- type CTRL+2 and CTRL+A a lot:</para>
-
- <programlisting>
-force=^^
-raisechar=^^</programlisting>
-
- <para>The ^^ is SHIFT+CTRL+6.</para>
- </sect2>
-
- <sect2>
- <title>How can I do file transfers with <command>tip</command>?</title>
-
- <para>If you are talking to another UNIX system, you can send and
- receive files with <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 you probably should use another
- protocol, like zmodem.</para>
- </sect2>
-
- <sect2>
- <title>How can I run zmodem 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 id="serialconsole-setup">
- <title>Setting Up the Serial Console</title>
-
- <para><emphasis>&a.yokota; and &a.wpaul;:</emphasis></para>
-
- <para><emphasis>The text is heavily based on
- <filename>/sys/i386/boot/biosboot/README.serial</filename> written by
- &a.wpaul;.</emphasis></para>
-
- <sect2 id="serialconsole-intro">
- <title>Introduction</title>
-
- <para>The FreeBSD/i386 operating system can boot on a system with only
- a dumb terminal on a serial port as a console. Such a configuration
- should be useful for two classes of people; system administrators who
- wish to install FreeBSD on a dedicated file/compute/terminal server
- machines that have no keyboard or monitor attached, and developers who
- want to debug the kernel or device drivers.</para>
-
- <para>Starting from version 3.1, FreeBSD/i386 employs a three stage
- bootstrap. The first two stages are in the boot block code which is
- stored at the beginning of the FreeBSD slice on the boot disk. The
- boot block will then load and run the boot loader
- (<filename>/boot/loader</filename>) as the third stage code. (See
- &man.boot.8; and &man.loader.8; for more details on the boot
- process.)</para>
-
- <para>In order to set up the serial console you must configure the boot
- block code, the boot loader code and the kernel.</para>
-
- <para>In FreeBSD version 3.0, the boot loader does not exist and there
- are only two stages in the bootstrap; the boot blocks directly load
- the kernel into memory. If you are using FreeBSD 3.0, then you should
- disregard any reference to the boot loader in this section. You can
- still use the serial port as a console.</para>
-
- <para>FreeBSD versions 2.X are quite different from 3.X, in that the
- serial port driver, &man.sio.4;, must be configured in a different
- way. This chapter will not describe the settings for version 2.X
- systems. If you are using these older versions of FreeBSD, please
- consult <filename>/sys/i386/boot/biosboot/README.serial</filename>
- instead.</para>
- </sect2>
-
- <sect2 id="serialconsole-howto">
- <title>6 Steps to Set up the Serial Console</title>
-
- <procedure>
- <step>
- <para>Prepare a serial cable.</para>
-
- <para>You will need either a null-modem cable or a standard serial
- cable and a null-modem adapter. See <xref linkend="term"> for
- a discussion on serial cables.</para>
- </step>
-
- <step>
- <para>Unplug your keyboard.</para>
-
- <para>Most PC systems probe for the keyboard during the Power-On
- Self-Test (POST) and will generate an error if the keyboard is not
- detected. Some machines complain loudly about the lack of a
- keyboard and will not continue to boot until it is plugged
- in.</para>
-
- <para>If your computer complains about the error, but boots anyway,
- then you do not have to do anything special. (One machine with a
- Phoenix BIOS that I have here merely says <errorname>Keyboard
- failed</errorname> then continues to boot normally.)</para>
-
- <para>If your computer refuses to boot without a keyboard attached
- then you will have to configure the BIOS so that it ignores this
- error (if it can). Consult your motherboard's manual for details
- on how to do this.</para>
-
- <tip>
- <para>Setting the keyboard to <quote>Not installed</quote> in the
- BIOS setup does <emphasis>not</emphasis> mean that you will not
- be able to use your keyboard. All this does is tell the BIOS
- not to probe for a keyboard at power-on so that it will not
- complain if the keyboard is not plugged in. You can leave the
- keyboard plugged in even with this flag set to <quote>Not
- installed</quote> and the keyboard will still work.</para>
- </tip>
-
- <note>
- <para>If your system has a PS/2 mouse, chances are very good that
- you may have to unplug your mouse as well as your keyboard.
- This is because PS/2 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. It is said that a
- Gateway 2000 Pentium 90Mhz system with an AMI BIOS that behaves
- this way. In general this is not a problem since the mouse is
- not much good without the keyboard anyway.</para>
- </note>
- </step>
-
- <step>
- <para>Plug a dumb terminal into <devicename>COM1:</devicename>
- (<devicename>sio0</devicename>).</para>
-
- <para>If you do not have a dumb terminal, you can use an old PC/XT
- with a modem program, or the serial port on another UNIX box. If
- you do not have a <devicename>COM1:</devicename>
- (<devicename>sio0</devicename>), get one. At this time, there is
- no way to select a port other than <devicename>COM1:</devicename>
- for the boot blocks without recompiling the boot blocks. If you
- are already using <devicename>COM1:</devicename> for another
- device, you will have to temporarily remove that device and
- install a new boot block and kernel once you get FreeBSD up and
- running. (It is assumed that <devicename>COM1:</devicename> will
- be available on a file/compute/terminal server anyway; if you
- really need <devicename>COM1:</devicename> for something else
- (and you can not switch that something else to
- <devicename>COM2:</devicename> (<devicename>sio1</devicename>)),
- then you probably should not even be bothering with all this in
- the first place.)</para>
- </step>
-
- <step>
- <para>Make sure the configuration file of your kernel has
- appropriate flags set for <devicename>COM1:</devicename>
- (<devicename>sio0</devicename>).</para>
-
- <para>Relevant flags are:</para>
-
- <variablelist>
- <varlistentry>
- <term><literal>0x10</literal></term>
-
- <listitem>
- <para>Enables console support for this unit. The other
- console flags are ignored unless this is set. Currently, at
- most one unit can have console support; the first one (in
- config file order) with this flag set is preferred. This
- option alone will not make the serial port the console. Set
- the following flag or use the <option>-h</option> option
- described below, together with this flag.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>0x20</literal></term>
-
- <listitem>
- <para>Forces this unit to be the console (unless there is
- another higher priority console), regardless of the
- <option>-h</option> option discussed below. This flag
- replaces the <literal>COMCONSOLE</literal> option in FreeBSD
- versions 2.X. The flag <literal>0x20</literal> must be used
- together with the <option>0x10</option> flag.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>0x40</literal></term>
-
- <listitem>
- <para>Reserves this unit (in conjunction with
- <literal>0x10</literal>) and makes the unit unavailable for
- normal access. You should not set this flag to the serial
- port unit which you want to use as the serial console. The
- only use of this flag is to designate the unit for kernel
- remote debugging. See <xref linkend="kerneldebug"> for more
- information on remote debugging.</para>
-
- <note>
- <para>In FreeBSD 4.0-CURRENT or later the semantics of the
- flag <literal>0x40</literal> are slightly different and
- there is another flag to specify a serial port for remote
- debugging.</para>
- </note>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>Example:</para>
-
- <programlisting>
-device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4</programlisting>
-
- <para>See &man.sio.4; for more details.</para>
-
- <para>If the flags were not set, you need to run UserConfig (on a
- different console) or recompile the kernel.</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 will instruct the boot block code how you would like
- to boot the system. In order to activate the serial console, you
- need one or more of the following options&mdash;if you want
- multiple options, include them all on the same line:</para>
-
- <variablelist>
- <varlistentry>
- <term><option>-h</option></term>
-
- <listitem>
- <para>Toggles internal and serial consoles. You can use this
- to switch console devices. For instance, if you boot from
- the internal (video) console, you can use
- <option>-h</option> to direct the boot loader and the kernel
- to use the serial port as its console device. Alternatively,
- if you boot from the serial port, you can use the
- <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 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 the <option>-h</option> option above. 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 the <option>-h</option> option.
- However, that the dual console configuration takes effect
- only during the boot block is running. Once the boot loader
- gets control, the console specified by the
- <option>-h</option> 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, the <option>-P</option> 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 laptop computers may not be
- properly found because of this limitation. If this is to
- be the case with your system, you have to abandon using
- the <option>-P</option> option. Unfortunately there is no
- workaround for this problem.</para>
- </note>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>Use either the <option>-P</option> option to select the
- console automatically, or the <option>-h</option> option to
- activate the serial console.</para>
-
- <para>You may include other options described in &man.boot.8; as
- well.</para>
-
- <para>The options, except for <option>-P</option>, will be passed to
- the boot loader (<filename>/boot/loader</filename>). The boot
- loader will determine which of the internal video or the serial
- port should become the console by examining the state of the
- <option>-h</option> option alone. This means that if you specify
- the <option>-D</option> option but not the <option>-h</option>
- option in <filename>/boot.config</filename>, you can use the
- serial port as the console only during the boot block; the boot
- loader will use the internal video display as the console.</para>
- </step>
-
- <step>
- <para>Boot the machine.</para>
-
- <para>When you start your FreeBSD box, the boot blocks will 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 you put <option>-P</option> in
- <filename>/boot.config</filename> and indicates presence/absence
- of the keyboard. These messages go to either serial or internal
- console, or both, depending on the option in
- <filename>/boot.config</filename>.</para>
-
- <informaltable frame="none">
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Options</entry>
- <entry>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 above messages, there will be a small pause before
- the boot blocks continue loading the boot loader and before any
- further messages printed to the console. Under normal
- circumstances, you do not need to interrupt the boot blocks, but
- you may want to do so in order to make sure things are set up
- correctly.</para>
-
- <para>Hit any key, other than Enter/Return, at the console to
- interrupt the boot process. The boot blocks will then prompt you
- for further action. You should now see something like:</para>
-
- <screen>>> FreeBSD/i386 BOOT
-Default: 0:wd(0,a)/boot/loader
-boot:</screen>
-
- <para>Verify the above message appears on either the serial or
- internal console or both, according to the options you put in
- <filename>/boot.config</filename>. If the message appears in the
- correct console, hit Enter/Return to continue the boot
- process.</para>
-
- <para>If you want the serial console but you do not see the prompt
- on the serial terminal, something is wrong with your settings. In
- the meantime, you enter <option>-h</option> and hit Enter/Return
- (if possible) 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>After the boot loader is loaded and you are in the third stage of
- the boot process you can still switch between the internal console and
- the serial console by setting appropriate environment variables in the
- boot loader. See <xref linkend="serialconsole-loader">.</para>
- </sect2>
-
- <sect2 id="serialconsole-summary">
- <title>Summary</title>
-
- <para>Here is the summary of various settings discussed in this section
- and the console eventually selected.</para>
-
- <sect3>
- <title>Case 1: You set the flags to 0x10 for sio0</title>
-
- <programlisting>device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4</programlisting>
-
- <informaltable frame="none">
- <tgroup cols="4">
- <thead>
- <row>
- <entry>Options in /boot.config</entry>
- <entry>Console during boot blocks</entry>
- <entry>Console during boot loader</entry>
- <entry>Console in kernel</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry>nothing</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- </row>
-
- <row>
- <entry><option>-h</option></entry>
- <entry>serial</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-D</option></entry>
- <entry>serial and internal</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- </row>
-
- <row>
- <entry><option>-Dh</option></entry>
- <entry>serial and internal</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-P</option>, keyboard present</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- </row>
-
- <row>
- <entry><option>-P</option>, keyboard absent</entry>
- <entry>serial and internal</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </sect3>
-
- <sect3>
- <title>Case 2: You set the flags to 0x30 for sio0</title>
-
- <programlisting>device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4</programlisting>
-
- <informaltable frame="none">
- <tgroup cols="4">
- <thead>
- <row>
- <entry>Options in /boot.config</entry>
- <entry>Console during boot blocks</entry>
- <entry>Console during boot loader</entry>
- <entry>Console in kernel</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry>nothing</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-h</option></entry>
- <entry>serial</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-D</option></entry>
- <entry>serial and internal</entry>
- <entry>internal</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-Dh</option></entry>
- <entry>serial and internal</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-P</option>, keyboard present</entry>
- <entry>internal</entry>
- <entry>internal</entry>
- <entry>serial</entry>
- </row>
-
- <row>
- <entry><option>-P</option>, keyboard absent</entry>
- <entry>serial and internal</entry>
- <entry>serial</entry>
- <entry>serial</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </sect3>
- </sect2>
-
- <sect2 id="serialconsole-tips">
- <title>Tips for the Serial Console</title>
-
- <sect3>
- <title>Setting A Faster Serial Port Speed</title>
-
- <para>By default the serial port settings are set to 9600 baud, 8
- bits, no parity, 1 stop bit. If you wish to change the speed, you
- need to recompile at least the boot blocks. Add the following line
- to <filename>/etc/make.conf</filename> and compile new boot
- blocks:</para>
-
- <programlisting>BOOT_COMCONSOLE_SPEED=19200</programlisting>
-
- <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, then
- you must also add the following option to the kernel configuration
- file and compile a new kernel:</para>
-
- <programlisting>options CONSPEED=19200</programlisting>
- </sect3>
-
- <sect3 id="serialconsole-com2">
- <title>Using Serial Port Other Than <devicename>sio0</devicename> For
- The Console</title>
-
- <para>Using a port other than <devicename>sio0</devicename> as the
- console requires some recompiling. If you want to use another
- serial port for whatever reasons, recompile the boot blocks, the
- boot loader and the kernel as follows.</para>
-
- <procedure>
- <step>
- <para>Get the kernel source.</para>
- </step>
-
- <step>
- <para>Edit <filename>/etc/make.conf</filename> and set
- <literal>BOOT_COMCONSOLE_PORT</literal> to the address of the
- port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only
- <devicename>sio0</devicename> through
- <devicename>sio3</devicename> (<devicename>COM1:</devicename>
- through <devicename>COM4:</devicename>) can be used; multiport
- serial cards will not work. No interrupt setting is
- needed.</para>
- </step>
-
- <step>
- <para>Create a custom kernel configuration file and add
- appropriate flags for the serial port you want to use. For
- example, if you want to make <devicename>sio1</devicename>
- (<devicename>COM2:</devicename>) the console:</para>
-
- <programlisting>device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3</programlisting>
-
- <para>or</para>
-
- <programlisting>device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3</programlisting>
-
- <para>The console flags for the other serial ports should not be
- set.</para>
- </step>
-
- <step>
- <para>Recompile and install the boot blocks:</para>
-
- <screen>&prompt.root; <userinput>cd /sys/boot/i386/boot2</userinput>
-&prompt.root; <userinput>make</userinput>
-&prompt.root; <userinput>make install</userinput></screen>
- </step>
-
- <step>
- <para>Recompile and install the boot loader:</para>
-
- <screen>&prompt.root; <userinput>cd /sys/boot/i386/loader</userinput>
-&prompt.root; <userinput>make</userinput>
-&prompt.root; <userinput>make install</userinput></screen>
- </step>
-
- <step>
- <para>Rebuild and install the kernel.</para>
- </step>
-
- <step>
- <para>Write the boot blocks to the boot disk with
- &man.disklabel.8; and boot from the new kernel.</para>
- </step>
- </procedure>
- </sect3>
-
- <sect3>
- <title>Entering the DDB Debugger from the Serial Line</title>
-
- <para>If you wish to drop into the kernel debugger from the serial
- console (useful for remote diagnostics, but also dangerous if you
- generate a spurious BREAK on the serial port!) then you should
- compile your kernel with the following options:</para>
-
- <programlisting>options BREAK_TO_DEBUGGER
-options DDB</programlisting>
- </sect3>
-
- <sect3>
- <title>Getting a Login Prompt on the Serial Console</title>
-
- <para>While this is not required, you may wish to get a
- <emphasis>login</emphasis> prompt over the serial line, now that you
- can see boot messages and can enter the kernel debugging session
- through the serial console. Here is how to do it.</para>
-
- <para>Open the file <filename>/etc/ttys</filename> with an editor
- and locate the lines:</para>
-
- <programlisting>ttyd0 "/usr/libexec/getty std.9600" unknown off secure
-ttyd1 "/usr/libexec/getty std.9600" unknown off secure
-ttyd2 "/usr/libexec/getty std.9600" unknown off secure
-ttyd3 "/usr/libexec/getty std.9600" unknown off secure</programlisting>
-
- <para><literal>ttyd0</literal> through <literal>ttyd3</literal>
- corresponds to <devicename>COM1</devicename> through
- <devicename>COM4</devicename>. Change <literal>off</literal> to
- <literal>on</literal> for the desired port. If you have changed the
- speed of the serial port, you need to change
- <literal>std.9600</literal> to match the current setting, e.g.
- <literal>std.19200</literal>.</para>
-
- <para>You may also want to change the terminal type from
- <literal>unknown</literal> to the actual type of your serial
- terminal.</para>
-
- <para>After editing the file, you must <command>kill -HUP 1</command>
- to make this change take effect.</para>
- </sect3>
- </sect2>
-
- <sect2 id="serialconsole-loader">
- <title>Changing Console from the Boot Loader</title>
-
- <para>Previous sections described how to set up the serial console by
- tweaking the boot block. This section shows that you can specify the
- console by entering some commands and environment variables in the
- boot loader. As the boot loader is invoked as the third stage of the
- boot process, after the boot block, the settings in the boot loader
- will override the settings in the boot block.</para>
-
- <sect3>
- <title>Setting Up the Serial Console</title>
-
- <para>You can easily specify the boot loader and the kernel to use the
- serial console by writing just one line in
- <filename>/boot/loader.rc</filename>:</para>
-
- <programlisting>set console=comconsole</programlisting>
-
- <para>This will take effect regardless of the settings in the boot
- block discussed in the previous section.</para>
-
- <para>You had better put the above line as the first line of
- <filename>/boot/loader.rc</filename> so as to see boot messages on
- the serial console as early as possible.</para>
-
- <para>Likewise, you can specify the internal console as:</para>
-
- <programlisting>set console=vidconsole</programlisting>
-
- <para>If you do not set the boot loader environment variable
- <envar>console</envar>, the boot loader, and subsequently the
- kernel, will use whichever console indicated by the
- <option>-h</option> option in the boot block.</para>
-
- <para>In versions 3.2 or later, you may specify the console in
- <filename>/boot/loader.conf.local</filename> or
- <filename>/boot/loader.conf</filename>, rather than in
- <filename>/boot/loader.rc</filename>. In this method your
- <filename>/boot/loader.rc</filename> should look like:</para>
-
- <programlisting>include /boot/loader.4th
-start</programlisting>
-
- <para>Then, create <filename>/boot/loader.conf.local</filename> and
- put the following line there.</para>
-
- <programlisting>console=comconsole</programlisting>
-
- <para>or</para>
-
- <programlisting>console=vidconsole</programlisting>
-
- <para>See &man.loader.conf.5; for more information.</para>
-
- <note>
- <para>At the moment, the boot loader has no option equivalent to the
- <option>-P</option> 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>
- </sect3>
-
- <sect3>
- <title>Using Serial Port Other than <devicename>sio0</devicename> for
- the Console</title>
-
- <para>You need to recompile the boot loader to use a serial port other
- than <devicename>sio0</devicename> for the serial console. Follow the
- procedure described in <xref linkend="serialconsole-com2">.</para>
- </sect3>
- </sect2>
-
- <sect2 id="serialconsole-caveats">
- <title>Caveats</title>
-
- <para>The idea here is to allow people to set up dedicated servers that
- require no graphics hardware or attached keyboards. Unfortunately,
- while (most?) every system will let you boot without a keyboard, there
- are quite a few that will not let you boot without a graphics adapter.
- Machines with AMI BIOSes can be configured to boot with no graphics
- adapter installed simply by changing the `graphics adapter' setting in
- the CMOS configuration to `Not installed.'</para>
-
- <para>However, many machines do not support this option and will refuse
- to boot if you have no display hardware in the system. With these
- machines, you'll have to leave some kind of graphics card plugged in,
- (even if it's just a junky mono board) although you will not have to
- attach a monitor into it. You might also try installing an AMI
- BIOS.</para>
- </sect2>
- </sect1>
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../book.sgml" "part" "chapter")
- End:
--->
-