diff --git a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml index 3cb7be6640..4c5f47c53f 100644 --- a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml @@ -1,2742 +1,2745 @@ Serial Communications Synopsis 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 terminal 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. Serial Basics Assembled from FAQ. 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. The ttydX (or cuaaX) 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 &prompt.root; stty -a -f /dev/ttyd1 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 initial state device. For example, to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default for ttyd5, do: &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff A good place to do this is in /etc/rc.serial. Now, an application will have these settings by default when it opens ttyd5. It can still change these settings to its liking, though. You can also prevent certain settings from being changed by an application by making adjustments to the lock state device. For example, to lock the speed of ttyd5 to 57600 bps, do &prompt.root; stty -f /dev/ttyld5 57600 Now, an application that opens ttyd5 and tries to change the speed of the port will be stuck with 57600 bps. Naturally, you should make the initial state and lock state devices writable only by root. The MAKEDEV script does not do this when it creates the device entries. Terminals Contributed by &a.kelly; 28 July 1996 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. Uses and Types of Terminals 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. 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 xterm window in the X Window System. 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. For FreeBSD, there are three kinds of terminals: Dumb terminals PCs acting as terminals X terminals The remaining subsections describe each kind. Dumb Terminals Dumb terminals are specialized pieces of hardware that let you connect to computers over serial lines. They are called dumb 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. 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. 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. PCs Acting As Terminals If a dumb terminal 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 terminal emulation software to run on the computer. 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. X Terminals X terminals are the most sophisticated kind of terminal available. Instead of connecting to a serial port, they usually connect to a network like Ethernet. Instead of being relegated to text-only applications, they can display any X application. We introduce X terminals just for the sake of completeness. However, this chapter does not cover setup, configuration, or use of X terminals. Cables and Ports 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 Configuration. Cables Because terminals use serial ports, you need to use serial—also known as RS-232C—cables to connect the terminal to the FreeBSD system. There are a couple of kinds of serial cables. Which one you'll use depends on the terminal you want to connect: If you are connecting a personal computer to act as a terminal, use a null-modem cable. A null-modem cable connects two computers or terminals together. 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 null-modem cable. If that does not work, then try a standard cable. Also, the serial port on both the terminal and your FreeBSD system must have connectors that will fit the cable you are using. Null-modem cables A null-modem cable passes some signals straight through, like signal ground, but switches other signals. For example, the send data pin on one end goes to the receive data pin on the other end. 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. Signal Pin # Pin # Signal TxD 2 connects to 3 RxD RxD 3 connects to 2 TxD DTR 20 connects to 6 DSR DSR 6 connects to 20 DTR SG 7 connects to 7 SG DCD 8 connects to 4 RTS RTS 4 5 CTS CTS 5 connects to 8 DCD For DCD to RTS, connect pins 4 to 5 internally in the connector hood, and then to pin 8 in the remote hood. Standard RS-232C Cables A standard serial cable passes all the RS-232C signals straight-through. That is, the send data pin on one end of the cable goes to the send data 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. Ports 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. Kinds of Ports 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. 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. 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. Port Names In FreeBSD, you access each serial port through an entry in the /dev directory. There are two different kinds of entries: Call-in ports are named /dev/ttydX where X 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. Call-out ports are named /dev/cuaaX. 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. See the &man.sio.4; manual page for more information. If you have connected a terminal to the first serial port (COM1 in DOS parlance), then you want to use /dev/ttyd0 to refer to the terminal. If it is on the second serial port (also known as COM2), it is /dev/ttyd1, and so forth. Note that you may have to configure your kernel to support each serial port, especially if you have a multiport serial card. See Configuring the FreeBSD Kernel for more information. Configuration 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—and that you have connected it. In a nutshell, you need to tell the init process, which is responsible for process control and initialization, to start a getty process, which is responsible for reading a login name and starting the login program. To do so, you have to edit the /etc/ttys file. First, use the su command to become root. Then, make the following changes to /etc/ttys: Add an line to /etc/ttys for the entry in the /dev directory for the serial port if it is not already there. Specify that /usr/libexec/getty be run on the port, and specify the appropriate getty type from the /etc/gettytab file. Specify the default terminal type. Set the port to on. Specify whether the port should be secure. Force init to reread the /etc/ttys file. As an optional step, you may wish to create a custom getty type for use in step 2 by making an entry in /etc/gettytab. 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. 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). For more information on the /etc/ttys file, see the &man.ttys.5; manual page. Adding an Entry to <filename>/etc/ttys</filename> First, you need to add an entry to the /etc/ttys file, unless one is already there. The /etc/ttys file lists all of the ports on your FreeBSD system where you want to allow logins. For example, the first virtual console ttyv0 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 /dev entry without the /dev part. When you installed your FreeBSD system, the /etc/ttys file included entries for the first four serial ports: ttyd0 through ttyd3. If you are attaching a terminal on one of those ports, you do not need to add an entry. In our example, we attached a Wyse-50 to the second serial port, ttyd1, 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 /etc/ttys file after we add the new entry: ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 Specifying the <replaceable>getty</replaceable> Type 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 /usr/libexec/getty. It is what provides the login: prompt. The program getty takes one (optional) parameter on its command line, the getty type. A getty type tells about characteristics on the terminal line, like bps rate and parity. The getty program reads these characteristics from the file /etc/gettytab. The file /etc/gettytab contains lots of entries for terminal lines both old and new. In almost all cases, the entries that start with the text std will work for hardwired terminals. These entries ignore parity. There is a std 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. When setting the getty type in the /etc/ttys file, make sure that the communications settings on the terminal match. 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 /etc/ttys file so far (showing just the two terminals in which we are interested): ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" Note that the second field—where we specify what program to run—appears in quotes. This is important, otherwise the type argument to getty might be interpreted as the next field. Specifying the Default Terminal Type The third field in the /etc/ttys file lists the default terminal type for the port. For dial-up ports, you typically put unknown or dialup 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. Users will usually use the tset program in their .login or .profile files to check the terminal type and prompt for one if necessary. By setting a terminal type in the /etc/ttys file, users can forego such prompting. To find out what terminal types FreeBSD supports, see the file /usr/share/misc/termcap. It lists about 600 terminal types. You can add more if you wish. See the &man.termcap.5; manual page for information. 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 /etc/ttys file: ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 Enabling the Port The next field in /etc/ttys, the fourth field, tells whether to enable the port. Putting on here will have the init process start the program in the second field, getty, which will prompt for a login. If you put off in the fourth field, there will be no getty, and hence no logins on the port. So, naturally, you want an on in this field. Here again is the /etc/ttys file. We have turned each port on. ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on Specifying Secure Ports We have arrived at the last field (well, almost: there is an optional window specifier, but we will ignore that). The last field tells whether the port is secure. What does secure mean? 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. How do you use secure and insecure ports? 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 su command. Because of this, you will have two records to help track down possible compromises of root privileges: both the login and the su command make records in the system log (and logins are also recorded in the wtmp file). 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 su command records. Which should you use? Just use insecure. Use insecure even for terminals not in public user areas or behind locked doors. It is quite easy to login and use su if you need superuser privileges. Here finally are the completed entries in the /etc/ttys file, with comments added to describe where the terminals are: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom Force <command>init</command> to Reread <filename>/etc/ttys</filename> When you boot FreeBSD, the first process, init, will read the /etc/ttys file and start the programs listed for each enabled port to prompt for logins. After you edit /etc/ttys, you do not want to have to reboot your system to get init to see the changes. So, init will reread /etc/ttys if it receives a SIGHUP (hangup) signal. So, after you have saved your changes to /etc/ttys, send SIGHUP to init by typing: &prompt.root; kill -HUP 1 (The init process always has process ID 1.) 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! Debugging your connection 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. No login prompt appears Make sure the terminal is plugged in and powered up. If it is a personal computer acting as a terminal, make sure it is running terminal emulation software on the correct serial port. Make sure the cable is connected firmly to both the terminal and the FreeBSD computer. Make sure it is the right kind of cable. Make sure the terminal and FreeBSD agree on the bps rate and parity settings. 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. Make sure that a getty process is running and serving the terminal. Type &prompt.root; ps -axww|grep getty to get a list of running getty processes. You should see an entry for the terminal. For example, the display 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 shows that a getty is running on the second serial port ttyd1 and is using the std.38400 entry in /etc/gettytab. If no getty process is running, make sure you have enabled the port in /etc/ttys. Make sure you have run kill -HUP 1. Garbage appears instead of a login prompt Make sure the terminal and FreeBSD agree on the bps rate and parity settings. Check the getty processes to make sure the correct getty type is in use. If not, edit /etc/ttys and run kill -HUP 1. Characters appear doubled; the password appears when typed Switch the terminal (or the terminal emulation software) from half duplex or local echo to full duplex. Dial-in Service Contributed by &a.ghelmer;. 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. Prerequisites 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 & modem and cabling. FreeBSD Version 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 (sio) 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. Terminology A quick rundown of terminology: bps Bits per Second — the rate at which data is transmitted DTE Data Terminal Equipment — for example, your computer DCE Data Communications Equipment — your modem RS-232 EIA standard for serial communications via hardware If you need more information about these terms and data communications in general, the author remembers reading that The RS-232 Bible (anybody have an ISBN?) is a good reference. When talking about communications data rates, the author does not use the term baud. Baud refers to the number of electrical state transitions that may be made in a period of time, while bps (bits per second) is the correct term to use (at least it does not seem to bother the curmudgeons quite a much). External v.s. Internal Modems 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. 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. Modems and Cables A background knowledge of these items is assumed 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) You are familiar with your modem's command set, or know where to look up needed commands You know how to configure your modem (probably via a terminal communications program) so you can set the non-volatile RAM parameters The first, connecting your modem, is usually simple — 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: Transmitted Data (SD) Received Data (RD) Request to Send (RTS) Clear to Send (CTS) Data Set Ready (DSR) Data Terminal Ready (DTR) Carrier Detect (CD) Signal Ground (SG) FreeBSD needs the RTS and CTS signals for flow-control at speeds above 2400bps, the CD signal to detect when a call has been answered or the line has been hung up, and the DTR 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. 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. 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. Serial Interface Considerations 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. Quick Overview Here is the process that FreeBSD follows to accept dial-up logins. A getty process, spawned by init, patiently waits to open the assigned serial port (/dev/ttyd0, for our example). The command ps ax might show this: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 When a user dials the modem's line and the modems connect, the CD line is asserted by the modem. The kernel notices that carrier has been detected and completes getty's open of the port. getty sends a login: prompt at the specified initial line speed. getty 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 getty's speed), getty tries adjusting the line speeds until it receives reasonable characters. We hope getty finds the correct speed and the user sees a login: prompt. After the user enters his/her login name, getty executes /usr/bin/login, which completes the login by asking for the user's password and then starting the user's shell. Let's dive into the configuration... Kernel Configuration FreeBSD kernels typically come prepared to search for four serial ports, known in the PC-DOS world as COM1:, COM2:, COM3:, and COM4:. FreeBSD can presently also handle dumb 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. To see if your kernel recognizes any of your serial ports, watch for messages while the kernel is booting, or use the /sbin/dmesg command to replay the kernel's boot messages. In particular, look for messages that start with the characters sio. Hint: to view just the messages that have the word sio, use the command: &prompt.root; /sbin/dmesg | grep 'sio' For example, on a system with four serial ports, these are the serial-port specific kernel boot messages: 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 If your kernel does not recognize all of your serial ports, you will probably need to configure a custom FreeBSD kernel for your system. Please see the BSD System Manager's Manual chapter on Building Berkeley Kernels with Config [the source for which is in /usr/src/share/doc/smm] and FreeBSD Configuration Options [in /sys/conf/options and in /sys/arch/conf/options.arch, with arch for example being i386] 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 (srcdist/srcsys.?? in FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source distribution in FreeBSD 2.0) to be able to configure and build kernels. Create a kernel configuration file for your system (if you have not already) by cding to /sys/i386/conf. Then, if you are creating a new custom configuration file, copy the file GENERICAH (or GENERICBT, if you have a BusTek SCSI controller on FreeBSD 1.x) to YOURSYS, where YOURSYS is the name of your system, but in upper-case letters. Edit the file, and change the device lines: 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 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. port "IO_COM1" is a substitution for port 0x3f8, IO_COM2 is 0x2f8, IO_COM3 is 0x3e8, and IO_COM4 is 0x2e8, 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 cannot 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). When you are finished adjusting the kernel configuration file, use the program config as documented in Building Berkeley Kernels with Config and the &man.config.8; manual page to prepare a kernel building directory, then build, install, and test the new kernel. Device Special Files Most devices in the kernel are accessed through device special files, which are located in the /dev directory. The sio devices are accessed through the /dev/ttyd? (dial-in) and /dev/cua0? (call-out) devices. On FreeBSD version 1.1.5 and higher, there are also initialization devices (/dev/ttyid? and /dev/cuai0?) and locking devices (/dev/ttyld? and /dev/cual0?). The initialization devices are used to initialize communications port parameters each time a port is opened, such as crtscts for modems which use CTS/RTS 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 & initializing devices, and setting terminal options, respectively. Making Device Special Files A shell script called MAKEDEV in the /dev 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 COM ports, so ignore it.) To use MAKEDEV to make dial-up device special files for COM1: (port 0), cd to /dev and issue the command MAKEDEV ttyd0. Likewise, to make dial-up device special files for COM2: (port 1), use MAKEDEV ttyd1. MAKEDEV not only creates the /dev/ttyd? device special files, but also creates the /dev/cua0? (and all of the initializing and locking special files under FreeBSD 1.1.5 and up) and removes the hardwired terminal special file /dev/tty0?, if it exists. After making new device special files, be sure to check the permissions on the files (especially the /dev/cua* files) to make sure that only users who should have access to those device special files can read & write on them — you probably do not want to allow your average user to use your modems to dial-out. The default permissions on the /dev/cua* files should be sufficient: 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 These permissions allow the user uucp and users in the group dialer to use the call-out devices. Configuration Files There are three system configuration files in the /etc directory that you will probably need to edit to allow dial-up access to your FreeBSD system. The first, /etc/gettytab, contains configuration information for the /usr/libexec/getty daemon. Second, /etc/ttys holds information that tells /sbin/init what tty devices should have getty processes running on them. Lastly, you can place port initialization commands in the /etc/rc.serial script if you have FreeBSD 1.1.5.1 or higher; otherwise, you can initialize ports in the /etc/rc.local script. 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. 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 getty does not understand any particular modem's connection speed reporting, getty gives a login: 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 <Enter> key until they see a recognizable prompt. If the data rates do not match, getty sees anything the user types as junk, tries going to the next speed and gives the login: 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 locked-speed method, but a user on a low-speed connection should receive better interactive response from full-screen programs. The author will try to give balanced configuration information, but is biased towards having the modem's data rate follow the connection rate. <filename>/etc/gettytab</filename> /etc/gettytab 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. Locked-Speed Config If you are locking your modem's data communications rate at a particular speed, you probably will not need to make any changes to /etc/gettytab. Matching-Speed Config You will need to setup an entry in /etc/gettytab to give getty information about the speeds you wish to use for your modem. If you have a 2400 bps modem, you can probably use the existing D2400 entry. This entry already exists in the FreeBSD 1.1.5.1 gettytab file, so you do not need to add it unless it is missing under your version of FreeBSD: # # 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: If you have a higher speed modem, you will probably need to add an entry in /etc/gettytab; here is an entry you could use for a 14.4 Kbps modem with a top interface speed of 19.2 Kbps: # # 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: On FreeBSD 1.1.5 and later, this will result in 8-bit, no parity connections. Under FreeBSD 1.1, add :np: parameters to the std.xxx entries at the top of the file for 8 bits, no parity; otherwise, the default is 7 bits, even parity. 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 nx= (next table) capability. Each of the lines uses a tc= (table continuation) entry to pick up the rest of the standard settings for a particular data rate. 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 gettytab entry starting a 57.6 Kbps: # # 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: If you have a slow CPU or a heavily loaded system and you do not have 16550A-based serial ports, you may receive sio silo errors at 57.6 Kbps. <filename>/etc/ttys</filename> /etc/ttys is the list of ttys for init to monitor. /etc/ttys also provides security information to login (user root may only login on ttys marked secure). See the manual page for &man.ttys.5; for more information. You will need to either modify existing lines in /etc/ttys or add new lines to make init run getty 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: ttyd0 "/usr/libexec/getty xxx" dialup on The first item in the above line is the device special file for this entry — ttyd0 means /dev/ttyd0 is the file that this getty will be watching. The second item, "/usr/libexec/getty xxx" (xxx will be replaced by the initial gettytab capability) is the process init will run on the device. The third item, dialup, is the default terminal type. The fourth parameter, on, indicates to init that the line is operational. There can be a fifth parameter, secure, but it should only be used for terminals which are physically secure (such as the system console). The default terminal type (dialup in the example above) may depend on local preferences. dialup is the traditional default terminal type on dial-up lines so that users may customize their login scripts to notice when the terminal is dialup and automatically adjust their terminal type. However, the author finds it easier at his site to specify vt102 as the default terminal type, since the users just use VT102 emulation on their remote systems. After you have made changes to /etc/ttys, you may send the init process a HUP signal to re-read the file. You can use the - command &prompt.root; kill -1 - 1 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 - init. + command + + &prompt.root; kill -HUP 1 + + 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 init. + Locked-Speed Config For a locked-speed configuration, your ttys entry needs to have a fixed-speed entry provided to getty. For a modem whose port speed is locked at 19.2 Kbps, the ttys entry might look like this: ttyd0 "/usr/libexec/getty std.19200" dialup on If your modem is locked at a different data rate, substitute the appropriate name for the std.speed entry for std.19200 from /etc/gettytab for your modem's data rate. Matching-Speed Config In a matching-speed configuration, your ttys entry needs to reference the appropriate beginning auto-baud (sic) entry in /etc/gettytab. For example, if you added the above suggested entry for a matching-speed modem that starts at 19.2 Kbps (the gettytab entry containing the V19200 starting point), your ttys entry might look like this: ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.serial</filename> or <filename>/etc/rc.local</filename> High-speed modems, like V.32, V.32bis, and V.34 modems, need to use hardware (RTS/CTS) flow control. You can add stty commands to /etc/rc.serial on FreeBSD 1.1.5.1 and up, or /etc/rc.local on FreeBSD 1.1, to set the hardware flow control flag in the FreeBSD kernel for the modem ports. For example, on a sample FreeBSD 1.1.5.1 system, /etc/rc.serial reads: #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts This sets the termios flag crtscts on serial port #1's (COM2:) dial-in and dial-out initialization devices. On an old FreeBSD 1.1 system, these entries were added to /etc/rc.local to set the crtscts flag on the devices: # 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 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. Modem Settings 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 tip under FreeBSD) to set the parameters. Connect to the modem using the same communications speed as the initial speed getty will use and configure the modem's non-volatile RAM to match these requirements: CD asserted when connected DTR asserted for operation; dropping DTR hangs up line & resets modem CTS transmitted data flow control Disable XON/XOFF flow control RTS received data flow control Quiet mode (no result codes) No command echo Please read the documentation for your modem to find out what commands and/or DIP switch settings you need to give it. For example, to set the above parameters on a USRobotics Sportster 14,400 external modem, one could give these commands to the modem: ATZ AT&C1&D2&H1&I0&R2&W 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. 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: Switch 1: UP — DTR Normal Switch 2: Do not care (Verbal Result Codes/Numeric Result Codes) Switch 3: UP — Suppress Result Codes Switch 4: DOWN — No echo, offline commands Switch 5: UP — Auto Answer Switch 6: UP — Carrier Detect Normal Switch 7: UP — Load NVRAM Defaults Switch 8: Do not care (Smart Mode/Dumb Mode) Result codes should be disabled/suppressed for dial-up modems to avoid problems that can occur if getty mistakenly gives a login: 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 getty and the modem. Locked-speed Config 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: ATZ AT&B1&W Matching-speed Config 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: ATZ AT&B2&W Checking the Modem's Configuration 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 ATI5 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 ATZ and then ATI4. If you have a different brand of modem, check your modem's manual to see how to double-check your modem's configuration parameters. Troubleshooting Here are a few steps you can follow to check out the dial-up modem on your system. Checking out the FreeBSD system 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 DTR indicator lights when the login: prompt appears on the system's console — if it lights up, that should mean that FreeBSD has started a getty process on the appropriate communications port and is waiting for the modem to accept a call. If the DTR indicator doesn't light, login to the FreeBSD system through the console and issue a ps ax to see if FreeBSD is trying to run a getty process on the correct port. You should see a lines like this among the processes displayed: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 and the modem has not accepted a call yet, this means that getty has completed its open on the communications port. This could indicate a problem with the cabling or a mis-configured modem, because getty should not be able to open the communications port until CD (carrier detect) has been asserted by the modem. If you do not see any getty processes waiting to open the desired ttyd? port, double-check your entries in /etc/ttys to see if there are any mistakes there. Also, check the log file /var/log/messages to see if there are any log messages from init or getty regarding any problems. If there are any messages, triple-check the configuration files /etc/ttys and /etc/gettytab, as well as the appropriate device special files /dev/ttyd?, for any mistakes, missing entries, or missing device special files. Try Dialing In 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 <Enter> about once per second. If you still do not see a login: prompt after a while, try sending a BREAK. If you are using a high-speed modem to do the dialing, try dialing again after locking the dialing modem's interface speed (via AT&B1 on a USR Sportster, for example). If you still cannot get a login: prompt, check /etc/gettytab again and double-check that The initial capability name specified in /etc/ttys for the line matches a name of a capability in /etc/gettytab Each nx= entry matches another gettytab capability name Each tc= entry matches another gettytab capability name 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 DTR is asserted. If the modem seems to be configured correctly, verify that the DTR line is asserted by checking the modem's indicator lights (if it has any). 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. Acknowledgments Thanks to these people for comments and advice: &a.kelly; for a number of good suggestions Dial-out Service Information integrated from FAQ. 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. This is useful to log onto a BBS. 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. Why cannot I run <command>tip</command> or <command>cu</command>? On your system, the programs tip and cu are probably executable only by uucp and group dialer. You can use the group dialer to control who has access to your modem or remote systems. Just add yourself to group dialer. Alternatively, you can let everyone on your system run tip and cu by typing: &prompt.root; chmod 4511 /usr/bin/tip You do not have to run this command for cu, since cu is just a hard link to tip. My stock Hayes modem is not supported, what can I do? Actually, the man page for tip is out of date. There is a generic Hayes dialer already built in. Just use at=hayes in your /etc/remote file. The Hayes driver is not smart enough to recognize some of the advanced features of newer modems—messages like BUSY, NO DIALTONE, or CONNECT 115200 will just confuse it. You should turn those messages off when you use tip (using ATX0&W). Also, the dial timeout for tip is 60 seconds. Your modem should use something less, or else tip will think there is a communication problem. Try ATS7=45&W. Actually, as shipped tip does not yet support it fully. The solution is to edit the file tipconf.h in the directory /usr/src/usr.bin/tip/tip Obviously you need the source distribution to do this. Edit the line #define HAYES 0 to #define HAYES 1. Then make and make install. Everything works nicely after that. How am I expected to enter these AT commands? Make what is called a direct entry in your /etc/remote file. For example, if your modem is hooked up to the first serial port, /dev/cuaa0, then put in the following line: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Use the highest bps rate your modem supports in the br capability. Then, type tip cuaa0 and you will be connected to your modem. If there is no /dev/cuaa0 on your system, do this: &prompt.root; cd /dev &prompt.root; MAKEDEV cuaa0 Or use cu as root with the following command: &prompt.root; cu -lline -sspeed line is the serial port (e.g./dev/cuaa0) and speed is the speed (e.g.57600). When you are done entering the AT commands hit ~. to exit. The <literal>@</literal> sign for the pn capability does not work! The @ sign in the phone number capability tells tip to look in /etc/phones for a phone number. But the @ sign is also a special character in capability files like /etc/remote. Escape it with a backslash: pn=\@ How can I dial a phone number on the command line? Put what is called a generic entry in your /etc/remote file. For example: 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: Then you can things like: &prompt.root; tip -115200 5551234 If you prefer cu over tip, use a generic cu entry: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: and type: &prompt.root; cu 5551234 -s 115200 Do I have to type in the bps rate every time I do that? Put in an entry for tip1200 or cu1200, but go ahead and use whatever bps rate is appropriate with the br capability. tip thinks a good default is 1200 bps which is why it looks for a tip1200 entry. You do not have to use 1200 bps, though. I access a number of hosts through a terminal server. Rather than waiting until you are connected and typing CONNECT <host> each time, use tip's cm capability. For example, these entries in /etc/remote: 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: will let you type tip pain or tip muffin to connect to the hosts pain or muffin; and tip deep13 to get to the terminal server. Can tip try more than one line for each site? This is often a problem where a university has several modem lines and several thousand students trying to use them... Make an entry for your university in /etc/remote and use @ for the pn capability: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Then, list the phone numbers for the university in /etc/phones: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip will try each one in the listed order, then give up. If you want to keep retrying, run tip in a while loop. Why do I have to hit CTRL+P twice to send CTRL+P once? CTRL+P is the default force character, used to tell tip that the next character is literal data. You can set the force character to any other character with the ~s escape, which means set a variable. Type ~sforce=single-char followed by a newline. single-char is any single character. If you leave out single-char, then the force character is the nul character, which you can get by typing CTRL+2 or CTRL+SPACE. A pretty good value for single-char is SHIFT+CTRL+6, which I have seen only used on some terminal servers. You can have the force character be whatever you want by specifying the following in your $HOME/.tiprc file: force=<single-char> Suddenly everything I type is in UPPER CASE?? You must have pressed CTRL+A, tip's raise character, specially designed for people with broken caps-lock keys. Use ~s as above and set the variable raisechar 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. Here is a sample .tiprc file perfect for Emacs users who need to type CTRL+2 and CTRL+A a lot: force=^^ raisechar=^^ The ^^ is SHIFT+CTRL+6. How can I do file transfers with <command>tip</command>? If you are talking to another UNIX system, you can send and receive files with ~p (put) and ~t (take). These commands run cat and echo on the remote system to accept and send files. The syntax is: ~p local-file remote-file ~t remote-file local-file There is no error checking, so you probably should use another protocol, like zmodem. How can I run zmodem with <command>tip</command>? To receive files, start the sending program on the remote end. Then, type ~C rz to begin receiving them locally. To send files, start the receiving program on the remote end. Then, type ~C sz files to send them to the remote system. Setting Up the Serial Console &a.yokota; and &a.wpaul;: The text is heavily based on /sys/i386/boot/biosboot/README.serial written by &a.wpaul;. Introduction 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. 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 (/boot/loader) as the third stage code. (See &man.boot.8; and &man.loader.8; for more details on the boot process.) In order to set up the serial console you must configure the boot block code, the boot loader code and the kernel. 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. 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 /sys/i386/boot/biosboot/README.serial instead. 6 Steps to Set up the Serial Console Prepare a serial cable. You will need either a null-modem cable or a standard serial cable and a null-modem adapter. See for a discussion on serial cables. Unplug your keyboard. 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. 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 Keyboard failed then continues to boot normally.) 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. Setting the keyboard to Not installed in the BIOS setup does not 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 Not installed and the keyboard will still work. 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. Plug a dumb terminal into COM1: (sio0). 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 COM1: (sio0), get one. At this time, there is no way to select a port other than COM1: for the boot blocks without recompiling the boot blocks. If you are already using COM1: 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 COM1: will be available on a file/compute/terminal server anyway; if you really need COM1: for something else (and you can not switch that something else to COM2: (sio1)), then you probably should not even be bothering with all this in the first place.) Make sure the configuration file of your kernel has appropriate flags set for COM1: (sio0). Relevant flags are: 0x10 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 described below, together with this flag. 0x20 Forces this unit to be the console (unless there is another higher priority console), regardless of the option discussed below. This flag replaces the COMCONSOLE option in FreeBSD versions 2.X. The flag 0x20 must be used together with the flag. 0x40 Reserves this unit (in conjunction with 0x10) 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 for more information on remote debugging. In FreeBSD 4.0-CURRENT or later the semantics of the flag 0x40 are slightly different and there is another flag to specify a serial port for remote debugging. Example: device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 See &man.sio.4; for more details. If the flags were not set, you need to run UserConfig (on a different console) or recompile the kernel. Create boot.config in the root directory of the a partition on the boot drive. 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—if you want multiple options, include them all on the same line: 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 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 to tell the boot loader and the kernel to use the video display as the console instead. 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 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. 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 becomes the only console. Makes the boot block probe the keyboard. If no keyboard is found, the and options are automatically set. Due to space constraints in the current version of the boot blocks, the 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. Unfortunately there is no workaround for this problem. Use either the option to select the console automatically, or the option to activate the serial console. You may include other options described in &man.boot.8; as well. The options, except for , will be passed to the boot loader (/boot/loader). 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 alone. This means that if you specify the option but not the option in /boot.config, 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. Boot the machine. When you start your FreeBSD box, the boot blocks will echo the contents of /boot.config to the console. For example; /boot.config: -P Keyboard: no The second line appears only if you put in /boot.config and indicates presence/absence of the keyboard. These messages go to either serial or internal console, or both, depending on the option in /boot.config. Options Message goes to none internal console serial console serial and internal consoles serial and internal consoles , keyboard present internal console , keyboard absent serial console 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. 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: >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/boot/loader boot: Verify the above message appears on either the serial or internal console or both, according to the options you put in /boot.config. If the message appears in the correct console, hit Enter/Return to continue the boot process. 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 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. 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 . Summary Here is the summary of various settings discussed in this section and the console eventually selected. Case 1: You set the flags to 0x10 for sio0 device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 Options in /boot.config Console during boot blocks Console during boot loader Console in kernel nothing internal internal internal serial serial serial serial and internal internal internal serial and internal serial serial , keyboard present internal internal internal , keyboard absent serial and internal serial serial Case 2: You set the flags to 0x30 for sio0 device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4 Options in /boot.config Console during boot blocks Console during boot loader Console in kernel nothing internal internal serial serial serial serial serial and internal internal serial serial and internal serial serial , keyboard present internal internal serial , keyboard absent serial and internal serial serial Tips for the Serial Console Setting A Faster Serial Port Speed 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 /etc/make.conf and compile new boot blocks: BOOT_COMCONSOLE_SPEED=19200 If the serial console is configured in some other way than by booting with , 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: options CONSPEED=19200 Using Serial Port Other Than <devicename>sio0</devicename> For The Console Using a port other than sio0 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. Get the kernel source. Edit /etc/make.conf and set BOOT_COMCONSOLE_PORT to the address of the port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only sio0 through sio3 (COM1: through COM4:) can be used; multiport serial cards will not work. No interrupt setting is needed. 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 sio1 (COM2:) the console: device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3 or device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3 The console flags for the other serial ports should not be set. Recompile and install the boot blocks: &prompt.root; cd /sys/boot/i386/boot2 &prompt.root; make &prompt.root; make install Recompile and install the boot loader: &prompt.root; cd /sys/boot/i386/loader &prompt.root; make &prompt.root; make install Rebuild and install the kernel. Write the boot blocks to the boot disk with &man.disklabel.8; and boot from the new kernel. Entering the DDB Debugger from the Serial Line 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: options BREAK_TO_DEBUGGER options DDB Getting a Login Prompt on the Serial Console While this is not required, you may wish to get a login 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. Open the file /etc/ttys with an editor and locate the lines: 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 ttyd0 through ttyd3 corresponds to COM1 through COM4. Change off to on for the desired port. If you have changed the speed of the serial port, you need to change std.9600 to match the current setting, e.g. std.19200. You may also want to change the terminal type from unknown to the actual type of your serial terminal. After editing the file, you must kill -HUP 1 to make this change take effect. Changing Console from the Boot Loader 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. Setting Up the Serial Console You can easily specify the boot loader and the kernel to use the serial console by writing just one line in /boot/loader.rc: set console=comconsole This will take effect regardless of the settings in the boot block discussed in the previous section. You had better put the above line as the first line of /boot/loader.rc so as to see boot messages on the serial console as early as possible. Likewise, you can specify the internal console as: set console=vidconsole If you do not set the boot loader environment variable console, the boot loader, and subsequently the kernel, will use whichever console indicated by the option in the boot block. In versions 3.2 or later, you may specify the console in /boot/loader.conf.local or /boot/loader.conf, rather than in /boot/loader.rc. In this method your /boot/loader.rc should look like: include /boot/loader.4th start Then, create /boot/loader.conf.local and put the following line there. console=comconsole or console=vidconsole See &man.loader.conf.5; for more information. At the moment, the boot loader has no option equivalent to the 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. Using Serial Port Other than <devicename>sio0</devicename> for the Console You need to recompile the boot loader to use a serial port other than sio0 for the serial console. Follow the procedure described in . Caveats 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.' 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. diff --git a/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml index 3cb7be6640..4c5f47c53f 100644 --- a/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml @@ -1,2742 +1,2745 @@ Serial Communications Synopsis 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 terminal 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. Serial Basics Assembled from FAQ. 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. The ttydX (or cuaaX) 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 &prompt.root; stty -a -f /dev/ttyd1 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 initial state device. For example, to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default for ttyd5, do: &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff A good place to do this is in /etc/rc.serial. Now, an application will have these settings by default when it opens ttyd5. It can still change these settings to its liking, though. You can also prevent certain settings from being changed by an application by making adjustments to the lock state device. For example, to lock the speed of ttyd5 to 57600 bps, do &prompt.root; stty -f /dev/ttyld5 57600 Now, an application that opens ttyd5 and tries to change the speed of the port will be stuck with 57600 bps. Naturally, you should make the initial state and lock state devices writable only by root. The MAKEDEV script does not do this when it creates the device entries. Terminals Contributed by &a.kelly; 28 July 1996 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. Uses and Types of Terminals 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. 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 xterm window in the X Window System. 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. For FreeBSD, there are three kinds of terminals: Dumb terminals PCs acting as terminals X terminals The remaining subsections describe each kind. Dumb Terminals Dumb terminals are specialized pieces of hardware that let you connect to computers over serial lines. They are called dumb 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. 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. 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. PCs Acting As Terminals If a dumb terminal 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 terminal emulation software to run on the computer. 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. X Terminals X terminals are the most sophisticated kind of terminal available. Instead of connecting to a serial port, they usually connect to a network like Ethernet. Instead of being relegated to text-only applications, they can display any X application. We introduce X terminals just for the sake of completeness. However, this chapter does not cover setup, configuration, or use of X terminals. Cables and Ports 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 Configuration. Cables Because terminals use serial ports, you need to use serial—also known as RS-232C—cables to connect the terminal to the FreeBSD system. There are a couple of kinds of serial cables. Which one you'll use depends on the terminal you want to connect: If you are connecting a personal computer to act as a terminal, use a null-modem cable. A null-modem cable connects two computers or terminals together. 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 null-modem cable. If that does not work, then try a standard cable. Also, the serial port on both the terminal and your FreeBSD system must have connectors that will fit the cable you are using. Null-modem cables A null-modem cable passes some signals straight through, like signal ground, but switches other signals. For example, the send data pin on one end goes to the receive data pin on the other end. 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. Signal Pin # Pin # Signal TxD 2 connects to 3 RxD RxD 3 connects to 2 TxD DTR 20 connects to 6 DSR DSR 6 connects to 20 DTR SG 7 connects to 7 SG DCD 8 connects to 4 RTS RTS 4 5 CTS CTS 5 connects to 8 DCD For DCD to RTS, connect pins 4 to 5 internally in the connector hood, and then to pin 8 in the remote hood. Standard RS-232C Cables A standard serial cable passes all the RS-232C signals straight-through. That is, the send data pin on one end of the cable goes to the send data 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. Ports 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. Kinds of Ports 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. 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. 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. Port Names In FreeBSD, you access each serial port through an entry in the /dev directory. There are two different kinds of entries: Call-in ports are named /dev/ttydX where X 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. Call-out ports are named /dev/cuaaX. 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. See the &man.sio.4; manual page for more information. If you have connected a terminal to the first serial port (COM1 in DOS parlance), then you want to use /dev/ttyd0 to refer to the terminal. If it is on the second serial port (also known as COM2), it is /dev/ttyd1, and so forth. Note that you may have to configure your kernel to support each serial port, especially if you have a multiport serial card. See Configuring the FreeBSD Kernel for more information. Configuration 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—and that you have connected it. In a nutshell, you need to tell the init process, which is responsible for process control and initialization, to start a getty process, which is responsible for reading a login name and starting the login program. To do so, you have to edit the /etc/ttys file. First, use the su command to become root. Then, make the following changes to /etc/ttys: Add an line to /etc/ttys for the entry in the /dev directory for the serial port if it is not already there. Specify that /usr/libexec/getty be run on the port, and specify the appropriate getty type from the /etc/gettytab file. Specify the default terminal type. Set the port to on. Specify whether the port should be secure. Force init to reread the /etc/ttys file. As an optional step, you may wish to create a custom getty type for use in step 2 by making an entry in /etc/gettytab. 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. 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). For more information on the /etc/ttys file, see the &man.ttys.5; manual page. Adding an Entry to <filename>/etc/ttys</filename> First, you need to add an entry to the /etc/ttys file, unless one is already there. The /etc/ttys file lists all of the ports on your FreeBSD system where you want to allow logins. For example, the first virtual console ttyv0 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 /dev entry without the /dev part. When you installed your FreeBSD system, the /etc/ttys file included entries for the first four serial ports: ttyd0 through ttyd3. If you are attaching a terminal on one of those ports, you do not need to add an entry. In our example, we attached a Wyse-50 to the second serial port, ttyd1, 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 /etc/ttys file after we add the new entry: ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 Specifying the <replaceable>getty</replaceable> Type 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 /usr/libexec/getty. It is what provides the login: prompt. The program getty takes one (optional) parameter on its command line, the getty type. A getty type tells about characteristics on the terminal line, like bps rate and parity. The getty program reads these characteristics from the file /etc/gettytab. The file /etc/gettytab contains lots of entries for terminal lines both old and new. In almost all cases, the entries that start with the text std will work for hardwired terminals. These entries ignore parity. There is a std 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. When setting the getty type in the /etc/ttys file, make sure that the communications settings on the terminal match. 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 /etc/ttys file so far (showing just the two terminals in which we are interested): ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" Note that the second field—where we specify what program to run—appears in quotes. This is important, otherwise the type argument to getty might be interpreted as the next field. Specifying the Default Terminal Type The third field in the /etc/ttys file lists the default terminal type for the port. For dial-up ports, you typically put unknown or dialup 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. Users will usually use the tset program in their .login or .profile files to check the terminal type and prompt for one if necessary. By setting a terminal type in the /etc/ttys file, users can forego such prompting. To find out what terminal types FreeBSD supports, see the file /usr/share/misc/termcap. It lists about 600 terminal types. You can add more if you wish. See the &man.termcap.5; manual page for information. 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 /etc/ttys file: ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 Enabling the Port The next field in /etc/ttys, the fourth field, tells whether to enable the port. Putting on here will have the init process start the program in the second field, getty, which will prompt for a login. If you put off in the fourth field, there will be no getty, and hence no logins on the port. So, naturally, you want an on in this field. Here again is the /etc/ttys file. We have turned each port on. ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on Specifying Secure Ports We have arrived at the last field (well, almost: there is an optional window specifier, but we will ignore that). The last field tells whether the port is secure. What does secure mean? 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. How do you use secure and insecure ports? 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 su command. Because of this, you will have two records to help track down possible compromises of root privileges: both the login and the su command make records in the system log (and logins are also recorded in the wtmp file). 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 su command records. Which should you use? Just use insecure. Use insecure even for terminals not in public user areas or behind locked doors. It is quite easy to login and use su if you need superuser privileges. Here finally are the completed entries in the /etc/ttys file, with comments added to describe where the terminals are: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom Force <command>init</command> to Reread <filename>/etc/ttys</filename> When you boot FreeBSD, the first process, init, will read the /etc/ttys file and start the programs listed for each enabled port to prompt for logins. After you edit /etc/ttys, you do not want to have to reboot your system to get init to see the changes. So, init will reread /etc/ttys if it receives a SIGHUP (hangup) signal. So, after you have saved your changes to /etc/ttys, send SIGHUP to init by typing: &prompt.root; kill -HUP 1 (The init process always has process ID 1.) 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! Debugging your connection 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. No login prompt appears Make sure the terminal is plugged in and powered up. If it is a personal computer acting as a terminal, make sure it is running terminal emulation software on the correct serial port. Make sure the cable is connected firmly to both the terminal and the FreeBSD computer. Make sure it is the right kind of cable. Make sure the terminal and FreeBSD agree on the bps rate and parity settings. 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. Make sure that a getty process is running and serving the terminal. Type &prompt.root; ps -axww|grep getty to get a list of running getty processes. You should see an entry for the terminal. For example, the display 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 shows that a getty is running on the second serial port ttyd1 and is using the std.38400 entry in /etc/gettytab. If no getty process is running, make sure you have enabled the port in /etc/ttys. Make sure you have run kill -HUP 1. Garbage appears instead of a login prompt Make sure the terminal and FreeBSD agree on the bps rate and parity settings. Check the getty processes to make sure the correct getty type is in use. If not, edit /etc/ttys and run kill -HUP 1. Characters appear doubled; the password appears when typed Switch the terminal (or the terminal emulation software) from half duplex or local echo to full duplex. Dial-in Service Contributed by &a.ghelmer;. 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. Prerequisites 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 & modem and cabling. FreeBSD Version 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 (sio) 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. Terminology A quick rundown of terminology: bps Bits per Second — the rate at which data is transmitted DTE Data Terminal Equipment — for example, your computer DCE Data Communications Equipment — your modem RS-232 EIA standard for serial communications via hardware If you need more information about these terms and data communications in general, the author remembers reading that The RS-232 Bible (anybody have an ISBN?) is a good reference. When talking about communications data rates, the author does not use the term baud. Baud refers to the number of electrical state transitions that may be made in a period of time, while bps (bits per second) is the correct term to use (at least it does not seem to bother the curmudgeons quite a much). External v.s. Internal Modems 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. 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. Modems and Cables A background knowledge of these items is assumed 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) You are familiar with your modem's command set, or know where to look up needed commands You know how to configure your modem (probably via a terminal communications program) so you can set the non-volatile RAM parameters The first, connecting your modem, is usually simple — 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: Transmitted Data (SD) Received Data (RD) Request to Send (RTS) Clear to Send (CTS) Data Set Ready (DSR) Data Terminal Ready (DTR) Carrier Detect (CD) Signal Ground (SG) FreeBSD needs the RTS and CTS signals for flow-control at speeds above 2400bps, the CD signal to detect when a call has been answered or the line has been hung up, and the DTR 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. 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. 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. Serial Interface Considerations 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. Quick Overview Here is the process that FreeBSD follows to accept dial-up logins. A getty process, spawned by init, patiently waits to open the assigned serial port (/dev/ttyd0, for our example). The command ps ax might show this: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 When a user dials the modem's line and the modems connect, the CD line is asserted by the modem. The kernel notices that carrier has been detected and completes getty's open of the port. getty sends a login: prompt at the specified initial line speed. getty 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 getty's speed), getty tries adjusting the line speeds until it receives reasonable characters. We hope getty finds the correct speed and the user sees a login: prompt. After the user enters his/her login name, getty executes /usr/bin/login, which completes the login by asking for the user's password and then starting the user's shell. Let's dive into the configuration... Kernel Configuration FreeBSD kernels typically come prepared to search for four serial ports, known in the PC-DOS world as COM1:, COM2:, COM3:, and COM4:. FreeBSD can presently also handle dumb 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. To see if your kernel recognizes any of your serial ports, watch for messages while the kernel is booting, or use the /sbin/dmesg command to replay the kernel's boot messages. In particular, look for messages that start with the characters sio. Hint: to view just the messages that have the word sio, use the command: &prompt.root; /sbin/dmesg | grep 'sio' For example, on a system with four serial ports, these are the serial-port specific kernel boot messages: 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 If your kernel does not recognize all of your serial ports, you will probably need to configure a custom FreeBSD kernel for your system. Please see the BSD System Manager's Manual chapter on Building Berkeley Kernels with Config [the source for which is in /usr/src/share/doc/smm] and FreeBSD Configuration Options [in /sys/conf/options and in /sys/arch/conf/options.arch, with arch for example being i386] 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 (srcdist/srcsys.?? in FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source distribution in FreeBSD 2.0) to be able to configure and build kernels. Create a kernel configuration file for your system (if you have not already) by cding to /sys/i386/conf. Then, if you are creating a new custom configuration file, copy the file GENERICAH (or GENERICBT, if you have a BusTek SCSI controller on FreeBSD 1.x) to YOURSYS, where YOURSYS is the name of your system, but in upper-case letters. Edit the file, and change the device lines: 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 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. port "IO_COM1" is a substitution for port 0x3f8, IO_COM2 is 0x2f8, IO_COM3 is 0x3e8, and IO_COM4 is 0x2e8, 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 cannot 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). When you are finished adjusting the kernel configuration file, use the program config as documented in Building Berkeley Kernels with Config and the &man.config.8; manual page to prepare a kernel building directory, then build, install, and test the new kernel. Device Special Files Most devices in the kernel are accessed through device special files, which are located in the /dev directory. The sio devices are accessed through the /dev/ttyd? (dial-in) and /dev/cua0? (call-out) devices. On FreeBSD version 1.1.5 and higher, there are also initialization devices (/dev/ttyid? and /dev/cuai0?) and locking devices (/dev/ttyld? and /dev/cual0?). The initialization devices are used to initialize communications port parameters each time a port is opened, such as crtscts for modems which use CTS/RTS 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 & initializing devices, and setting terminal options, respectively. Making Device Special Files A shell script called MAKEDEV in the /dev 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 COM ports, so ignore it.) To use MAKEDEV to make dial-up device special files for COM1: (port 0), cd to /dev and issue the command MAKEDEV ttyd0. Likewise, to make dial-up device special files for COM2: (port 1), use MAKEDEV ttyd1. MAKEDEV not only creates the /dev/ttyd? device special files, but also creates the /dev/cua0? (and all of the initializing and locking special files under FreeBSD 1.1.5 and up) and removes the hardwired terminal special file /dev/tty0?, if it exists. After making new device special files, be sure to check the permissions on the files (especially the /dev/cua* files) to make sure that only users who should have access to those device special files can read & write on them — you probably do not want to allow your average user to use your modems to dial-out. The default permissions on the /dev/cua* files should be sufficient: 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 These permissions allow the user uucp and users in the group dialer to use the call-out devices. Configuration Files There are three system configuration files in the /etc directory that you will probably need to edit to allow dial-up access to your FreeBSD system. The first, /etc/gettytab, contains configuration information for the /usr/libexec/getty daemon. Second, /etc/ttys holds information that tells /sbin/init what tty devices should have getty processes running on them. Lastly, you can place port initialization commands in the /etc/rc.serial script if you have FreeBSD 1.1.5.1 or higher; otherwise, you can initialize ports in the /etc/rc.local script. 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. 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 getty does not understand any particular modem's connection speed reporting, getty gives a login: 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 <Enter> key until they see a recognizable prompt. If the data rates do not match, getty sees anything the user types as junk, tries going to the next speed and gives the login: 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 locked-speed method, but a user on a low-speed connection should receive better interactive response from full-screen programs. The author will try to give balanced configuration information, but is biased towards having the modem's data rate follow the connection rate. <filename>/etc/gettytab</filename> /etc/gettytab 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. Locked-Speed Config If you are locking your modem's data communications rate at a particular speed, you probably will not need to make any changes to /etc/gettytab. Matching-Speed Config You will need to setup an entry in /etc/gettytab to give getty information about the speeds you wish to use for your modem. If you have a 2400 bps modem, you can probably use the existing D2400 entry. This entry already exists in the FreeBSD 1.1.5.1 gettytab file, so you do not need to add it unless it is missing under your version of FreeBSD: # # 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: If you have a higher speed modem, you will probably need to add an entry in /etc/gettytab; here is an entry you could use for a 14.4 Kbps modem with a top interface speed of 19.2 Kbps: # # 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: On FreeBSD 1.1.5 and later, this will result in 8-bit, no parity connections. Under FreeBSD 1.1, add :np: parameters to the std.xxx entries at the top of the file for 8 bits, no parity; otherwise, the default is 7 bits, even parity. 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 nx= (next table) capability. Each of the lines uses a tc= (table continuation) entry to pick up the rest of the standard settings for a particular data rate. 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 gettytab entry starting a 57.6 Kbps: # # 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: If you have a slow CPU or a heavily loaded system and you do not have 16550A-based serial ports, you may receive sio silo errors at 57.6 Kbps. <filename>/etc/ttys</filename> /etc/ttys is the list of ttys for init to monitor. /etc/ttys also provides security information to login (user root may only login on ttys marked secure). See the manual page for &man.ttys.5; for more information. You will need to either modify existing lines in /etc/ttys or add new lines to make init run getty 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: ttyd0 "/usr/libexec/getty xxx" dialup on The first item in the above line is the device special file for this entry — ttyd0 means /dev/ttyd0 is the file that this getty will be watching. The second item, "/usr/libexec/getty xxx" (xxx will be replaced by the initial gettytab capability) is the process init will run on the device. The third item, dialup, is the default terminal type. The fourth parameter, on, indicates to init that the line is operational. There can be a fifth parameter, secure, but it should only be used for terminals which are physically secure (such as the system console). The default terminal type (dialup in the example above) may depend on local preferences. dialup is the traditional default terminal type on dial-up lines so that users may customize their login scripts to notice when the terminal is dialup and automatically adjust their terminal type. However, the author finds it easier at his site to specify vt102 as the default terminal type, since the users just use VT102 emulation on their remote systems. After you have made changes to /etc/ttys, you may send the init process a HUP signal to re-read the file. You can use the - command &prompt.root; kill -1 - 1 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 - init. + command + + &prompt.root; kill -HUP 1 + + 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 init. + Locked-Speed Config For a locked-speed configuration, your ttys entry needs to have a fixed-speed entry provided to getty. For a modem whose port speed is locked at 19.2 Kbps, the ttys entry might look like this: ttyd0 "/usr/libexec/getty std.19200" dialup on If your modem is locked at a different data rate, substitute the appropriate name for the std.speed entry for std.19200 from /etc/gettytab for your modem's data rate. Matching-Speed Config In a matching-speed configuration, your ttys entry needs to reference the appropriate beginning auto-baud (sic) entry in /etc/gettytab. For example, if you added the above suggested entry for a matching-speed modem that starts at 19.2 Kbps (the gettytab entry containing the V19200 starting point), your ttys entry might look like this: ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.serial</filename> or <filename>/etc/rc.local</filename> High-speed modems, like V.32, V.32bis, and V.34 modems, need to use hardware (RTS/CTS) flow control. You can add stty commands to /etc/rc.serial on FreeBSD 1.1.5.1 and up, or /etc/rc.local on FreeBSD 1.1, to set the hardware flow control flag in the FreeBSD kernel for the modem ports. For example, on a sample FreeBSD 1.1.5.1 system, /etc/rc.serial reads: #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts This sets the termios flag crtscts on serial port #1's (COM2:) dial-in and dial-out initialization devices. On an old FreeBSD 1.1 system, these entries were added to /etc/rc.local to set the crtscts flag on the devices: # 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 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. Modem Settings 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 tip under FreeBSD) to set the parameters. Connect to the modem using the same communications speed as the initial speed getty will use and configure the modem's non-volatile RAM to match these requirements: CD asserted when connected DTR asserted for operation; dropping DTR hangs up line & resets modem CTS transmitted data flow control Disable XON/XOFF flow control RTS received data flow control Quiet mode (no result codes) No command echo Please read the documentation for your modem to find out what commands and/or DIP switch settings you need to give it. For example, to set the above parameters on a USRobotics Sportster 14,400 external modem, one could give these commands to the modem: ATZ AT&C1&D2&H1&I0&R2&W 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. 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: Switch 1: UP — DTR Normal Switch 2: Do not care (Verbal Result Codes/Numeric Result Codes) Switch 3: UP — Suppress Result Codes Switch 4: DOWN — No echo, offline commands Switch 5: UP — Auto Answer Switch 6: UP — Carrier Detect Normal Switch 7: UP — Load NVRAM Defaults Switch 8: Do not care (Smart Mode/Dumb Mode) Result codes should be disabled/suppressed for dial-up modems to avoid problems that can occur if getty mistakenly gives a login: 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 getty and the modem. Locked-speed Config 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: ATZ AT&B1&W Matching-speed Config 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: ATZ AT&B2&W Checking the Modem's Configuration 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 ATI5 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 ATZ and then ATI4. If you have a different brand of modem, check your modem's manual to see how to double-check your modem's configuration parameters. Troubleshooting Here are a few steps you can follow to check out the dial-up modem on your system. Checking out the FreeBSD system 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 DTR indicator lights when the login: prompt appears on the system's console — if it lights up, that should mean that FreeBSD has started a getty process on the appropriate communications port and is waiting for the modem to accept a call. If the DTR indicator doesn't light, login to the FreeBSD system through the console and issue a ps ax to see if FreeBSD is trying to run a getty process on the correct port. You should see a lines like this among the processes displayed: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 and the modem has not accepted a call yet, this means that getty has completed its open on the communications port. This could indicate a problem with the cabling or a mis-configured modem, because getty should not be able to open the communications port until CD (carrier detect) has been asserted by the modem. If you do not see any getty processes waiting to open the desired ttyd? port, double-check your entries in /etc/ttys to see if there are any mistakes there. Also, check the log file /var/log/messages to see if there are any log messages from init or getty regarding any problems. If there are any messages, triple-check the configuration files /etc/ttys and /etc/gettytab, as well as the appropriate device special files /dev/ttyd?, for any mistakes, missing entries, or missing device special files. Try Dialing In 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 <Enter> about once per second. If you still do not see a login: prompt after a while, try sending a BREAK. If you are using a high-speed modem to do the dialing, try dialing again after locking the dialing modem's interface speed (via AT&B1 on a USR Sportster, for example). If you still cannot get a login: prompt, check /etc/gettytab again and double-check that The initial capability name specified in /etc/ttys for the line matches a name of a capability in /etc/gettytab Each nx= entry matches another gettytab capability name Each tc= entry matches another gettytab capability name 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 DTR is asserted. If the modem seems to be configured correctly, verify that the DTR line is asserted by checking the modem's indicator lights (if it has any). 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. Acknowledgments Thanks to these people for comments and advice: &a.kelly; for a number of good suggestions Dial-out Service Information integrated from FAQ. 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. This is useful to log onto a BBS. 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. Why cannot I run <command>tip</command> or <command>cu</command>? On your system, the programs tip and cu are probably executable only by uucp and group dialer. You can use the group dialer to control who has access to your modem or remote systems. Just add yourself to group dialer. Alternatively, you can let everyone on your system run tip and cu by typing: &prompt.root; chmod 4511 /usr/bin/tip You do not have to run this command for cu, since cu is just a hard link to tip. My stock Hayes modem is not supported, what can I do? Actually, the man page for tip is out of date. There is a generic Hayes dialer already built in. Just use at=hayes in your /etc/remote file. The Hayes driver is not smart enough to recognize some of the advanced features of newer modems—messages like BUSY, NO DIALTONE, or CONNECT 115200 will just confuse it. You should turn those messages off when you use tip (using ATX0&W). Also, the dial timeout for tip is 60 seconds. Your modem should use something less, or else tip will think there is a communication problem. Try ATS7=45&W. Actually, as shipped tip does not yet support it fully. The solution is to edit the file tipconf.h in the directory /usr/src/usr.bin/tip/tip Obviously you need the source distribution to do this. Edit the line #define HAYES 0 to #define HAYES 1. Then make and make install. Everything works nicely after that. How am I expected to enter these AT commands? Make what is called a direct entry in your /etc/remote file. For example, if your modem is hooked up to the first serial port, /dev/cuaa0, then put in the following line: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Use the highest bps rate your modem supports in the br capability. Then, type tip cuaa0 and you will be connected to your modem. If there is no /dev/cuaa0 on your system, do this: &prompt.root; cd /dev &prompt.root; MAKEDEV cuaa0 Or use cu as root with the following command: &prompt.root; cu -lline -sspeed line is the serial port (e.g./dev/cuaa0) and speed is the speed (e.g.57600). When you are done entering the AT commands hit ~. to exit. The <literal>@</literal> sign for the pn capability does not work! The @ sign in the phone number capability tells tip to look in /etc/phones for a phone number. But the @ sign is also a special character in capability files like /etc/remote. Escape it with a backslash: pn=\@ How can I dial a phone number on the command line? Put what is called a generic entry in your /etc/remote file. For example: 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: Then you can things like: &prompt.root; tip -115200 5551234 If you prefer cu over tip, use a generic cu entry: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: and type: &prompt.root; cu 5551234 -s 115200 Do I have to type in the bps rate every time I do that? Put in an entry for tip1200 or cu1200, but go ahead and use whatever bps rate is appropriate with the br capability. tip thinks a good default is 1200 bps which is why it looks for a tip1200 entry. You do not have to use 1200 bps, though. I access a number of hosts through a terminal server. Rather than waiting until you are connected and typing CONNECT <host> each time, use tip's cm capability. For example, these entries in /etc/remote: 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: will let you type tip pain or tip muffin to connect to the hosts pain or muffin; and tip deep13 to get to the terminal server. Can tip try more than one line for each site? This is often a problem where a university has several modem lines and several thousand students trying to use them... Make an entry for your university in /etc/remote and use @ for the pn capability: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Then, list the phone numbers for the university in /etc/phones: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip will try each one in the listed order, then give up. If you want to keep retrying, run tip in a while loop. Why do I have to hit CTRL+P twice to send CTRL+P once? CTRL+P is the default force character, used to tell tip that the next character is literal data. You can set the force character to any other character with the ~s escape, which means set a variable. Type ~sforce=single-char followed by a newline. single-char is any single character. If you leave out single-char, then the force character is the nul character, which you can get by typing CTRL+2 or CTRL+SPACE. A pretty good value for single-char is SHIFT+CTRL+6, which I have seen only used on some terminal servers. You can have the force character be whatever you want by specifying the following in your $HOME/.tiprc file: force=<single-char> Suddenly everything I type is in UPPER CASE?? You must have pressed CTRL+A, tip's raise character, specially designed for people with broken caps-lock keys. Use ~s as above and set the variable raisechar 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. Here is a sample .tiprc file perfect for Emacs users who need to type CTRL+2 and CTRL+A a lot: force=^^ raisechar=^^ The ^^ is SHIFT+CTRL+6. How can I do file transfers with <command>tip</command>? If you are talking to another UNIX system, you can send and receive files with ~p (put) and ~t (take). These commands run cat and echo on the remote system to accept and send files. The syntax is: ~p local-file remote-file ~t remote-file local-file There is no error checking, so you probably should use another protocol, like zmodem. How can I run zmodem with <command>tip</command>? To receive files, start the sending program on the remote end. Then, type ~C rz to begin receiving them locally. To send files, start the receiving program on the remote end. Then, type ~C sz files to send them to the remote system. Setting Up the Serial Console &a.yokota; and &a.wpaul;: The text is heavily based on /sys/i386/boot/biosboot/README.serial written by &a.wpaul;. Introduction 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. 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 (/boot/loader) as the third stage code. (See &man.boot.8; and &man.loader.8; for more details on the boot process.) In order to set up the serial console you must configure the boot block code, the boot loader code and the kernel. 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. 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 /sys/i386/boot/biosboot/README.serial instead. 6 Steps to Set up the Serial Console Prepare a serial cable. You will need either a null-modem cable or a standard serial cable and a null-modem adapter. See for a discussion on serial cables. Unplug your keyboard. 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. 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 Keyboard failed then continues to boot normally.) 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. Setting the keyboard to Not installed in the BIOS setup does not 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 Not installed and the keyboard will still work. 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. Plug a dumb terminal into COM1: (sio0). 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 COM1: (sio0), get one. At this time, there is no way to select a port other than COM1: for the boot blocks without recompiling the boot blocks. If you are already using COM1: 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 COM1: will be available on a file/compute/terminal server anyway; if you really need COM1: for something else (and you can not switch that something else to COM2: (sio1)), then you probably should not even be bothering with all this in the first place.) Make sure the configuration file of your kernel has appropriate flags set for COM1: (sio0). Relevant flags are: 0x10 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 described below, together with this flag. 0x20 Forces this unit to be the console (unless there is another higher priority console), regardless of the option discussed below. This flag replaces the COMCONSOLE option in FreeBSD versions 2.X. The flag 0x20 must be used together with the flag. 0x40 Reserves this unit (in conjunction with 0x10) 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 for more information on remote debugging. In FreeBSD 4.0-CURRENT or later the semantics of the flag 0x40 are slightly different and there is another flag to specify a serial port for remote debugging. Example: device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 See &man.sio.4; for more details. If the flags were not set, you need to run UserConfig (on a different console) or recompile the kernel. Create boot.config in the root directory of the a partition on the boot drive. 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—if you want multiple options, include them all on the same line: 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 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 to tell the boot loader and the kernel to use the video display as the console instead. 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 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. 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 becomes the only console. Makes the boot block probe the keyboard. If no keyboard is found, the and options are automatically set. Due to space constraints in the current version of the boot blocks, the 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. Unfortunately there is no workaround for this problem. Use either the option to select the console automatically, or the option to activate the serial console. You may include other options described in &man.boot.8; as well. The options, except for , will be passed to the boot loader (/boot/loader). 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 alone. This means that if you specify the option but not the option in /boot.config, 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. Boot the machine. When you start your FreeBSD box, the boot blocks will echo the contents of /boot.config to the console. For example; /boot.config: -P Keyboard: no The second line appears only if you put in /boot.config and indicates presence/absence of the keyboard. These messages go to either serial or internal console, or both, depending on the option in /boot.config. Options Message goes to none internal console serial console serial and internal consoles serial and internal consoles , keyboard present internal console , keyboard absent serial console 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. 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: >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/boot/loader boot: Verify the above message appears on either the serial or internal console or both, according to the options you put in /boot.config. If the message appears in the correct console, hit Enter/Return to continue the boot process. 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 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. 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 . Summary Here is the summary of various settings discussed in this section and the console eventually selected. Case 1: You set the flags to 0x10 for sio0 device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 Options in /boot.config Console during boot blocks Console during boot loader Console in kernel nothing internal internal internal serial serial serial serial and internal internal internal serial and internal serial serial , keyboard present internal internal internal , keyboard absent serial and internal serial serial Case 2: You set the flags to 0x30 for sio0 device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4 Options in /boot.config Console during boot blocks Console during boot loader Console in kernel nothing internal internal serial serial serial serial serial and internal internal serial serial and internal serial serial , keyboard present internal internal serial , keyboard absent serial and internal serial serial Tips for the Serial Console Setting A Faster Serial Port Speed 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 /etc/make.conf and compile new boot blocks: BOOT_COMCONSOLE_SPEED=19200 If the serial console is configured in some other way than by booting with , 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: options CONSPEED=19200 Using Serial Port Other Than <devicename>sio0</devicename> For The Console Using a port other than sio0 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. Get the kernel source. Edit /etc/make.conf and set BOOT_COMCONSOLE_PORT to the address of the port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only sio0 through sio3 (COM1: through COM4:) can be used; multiport serial cards will not work. No interrupt setting is needed. 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 sio1 (COM2:) the console: device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3 or device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3 The console flags for the other serial ports should not be set. Recompile and install the boot blocks: &prompt.root; cd /sys/boot/i386/boot2 &prompt.root; make &prompt.root; make install Recompile and install the boot loader: &prompt.root; cd /sys/boot/i386/loader &prompt.root; make &prompt.root; make install Rebuild and install the kernel. Write the boot blocks to the boot disk with &man.disklabel.8; and boot from the new kernel. Entering the DDB Debugger from the Serial Line 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: options BREAK_TO_DEBUGGER options DDB Getting a Login Prompt on the Serial Console While this is not required, you may wish to get a login 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. Open the file /etc/ttys with an editor and locate the lines: 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 ttyd0 through ttyd3 corresponds to COM1 through COM4. Change off to on for the desired port. If you have changed the speed of the serial port, you need to change std.9600 to match the current setting, e.g. std.19200. You may also want to change the terminal type from unknown to the actual type of your serial terminal. After editing the file, you must kill -HUP 1 to make this change take effect. Changing Console from the Boot Loader 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. Setting Up the Serial Console You can easily specify the boot loader and the kernel to use the serial console by writing just one line in /boot/loader.rc: set console=comconsole This will take effect regardless of the settings in the boot block discussed in the previous section. You had better put the above line as the first line of /boot/loader.rc so as to see boot messages on the serial console as early as possible. Likewise, you can specify the internal console as: set console=vidconsole If you do not set the boot loader environment variable console, the boot loader, and subsequently the kernel, will use whichever console indicated by the option in the boot block. In versions 3.2 or later, you may specify the console in /boot/loader.conf.local or /boot/loader.conf, rather than in /boot/loader.rc. In this method your /boot/loader.rc should look like: include /boot/loader.4th start Then, create /boot/loader.conf.local and put the following line there. console=comconsole or console=vidconsole See &man.loader.conf.5; for more information. At the moment, the boot loader has no option equivalent to the 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. Using Serial Port Other than <devicename>sio0</devicename> for the Console You need to recompile the boot loader to use a serial port other than sio0 for the serial console. Follow the procedure described in . Caveats 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.' 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.