From owner-svn-doc-all@FreeBSD.ORG Wed May 7 20:37:49 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 359DB460; Wed, 7 May 2014 20:37:49 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21202BB5; Wed, 7 May 2014 20:37:49 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s47KbnDQ073821; Wed, 7 May 2014 20:37:49 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s47Kbnhw073820; Wed, 7 May 2014 20:37:49 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201405072037.s47Kbnhw073820@svn.freebsd.org> From: Dru Lavigne Date: Wed, 7 May 2014 20:37:49 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44790 - head/en_US.ISO8859-1/books/handbook/serialcomms X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:37:49 -0000 Author: dru Date: Wed May 7 20:37:48 2014 New Revision: 44790 URL: http://svnweb.freebsd.org/changeset/doc/44790 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml Wed May 7 19:51:05 2014 (r44789) +++ head/en_US.ISO8859-1/books/handbook/serialcomms/chapter.xml Wed May 7 20:37:48 2014 (r44790) @@ -104,112 +104,110 @@ When referring to communication data rates, this section - does not use the term baud. Baud refers to the - number of electrical state transitions made in a - period of time, while bps is the - correct term to use. - - To connect a serial terminal to a &os; system, a - serial port on the computer and the proper cable to connect to - the serial device are needed. Users who are already familiar - with serial hardware and cabling can safely skip this - section. + does not use the term baud. Baud refers + to the number of electrical state transitions made in a period + of time, while bps is the correct term to + use. + + To connect a serial terminal to a &os; system, a serial port + on the computer and the proper cable to connect to the serial + device are needed. Users who are already familiar with serial + hardware and cabling can safely skip this section. Serial Cables and Ports There are several different kinds of serial cables. The two most common types are null-modem cables and standard - RS-232 cables. The documentation for the hardware should - describe the type of cable required. + RS-232 cables. The documentation for the + hardware should describe the type of cable required. These two types of cables differ in how the wires are connected to the connector. Each wire represents a signal, with the defined signals summarized in . A standard serial cable passes all of the RS-232C signals - straight through. For example, the Transmitted Data pin on - one end of the cable goes to the Transmitted - Data pin on the other end. This is the type of - cable used to connect a modem to the &os; system, and is also - appropriate for some terminals. - - A null-modem cable - switches the Transmitted Data pin of the - connector on one end with the Received - Data pin on the other end. The connector can be - either a DB-25 or a + straight through. For example, the Transmitted + Data pin on one end of the cable goes to the + Transmitted Data pin on the other end. This is + the type of cable used to connect a modem to the &os; system, + and is also appropriate for some terminals. + + A null-modem cable switches the Transmitted + Data pin of the connector on one end with the + Received Data pin on the other end. The + connector can be either a DB-25 or a DB-9. - A null-modem cable can be constructed - using the pin connections summarized in , , and . While the standard - calls for a straight-through pin 1 to pin 1 - Protective Ground line, it is often - omitted. Some terminals work using only pins 2, 3, and 7, - while others require different configurations. When in doubt, - refer to the documentation for the hardware. + A null-modem cable can be constructed using the pin + connections summarized in , + , and . While the standard calls for + a straight-through pin 1 to pin 1 Protective + Ground line, it is often omitted. Some terminals + work using only pins 2, 3, and 7, while others require + different configurations. When in doubt, refer to the + documentation for the hardware. null-modem cable - - <acronym>RS-232C</acronym> Signal Names +
+ <acronym>RS-232C</acronym> Signal Names - - - - Acronyms - Names - - - - - - RD - Received Data - - - - TD - Transmitted Data - - - - DTR - Data Terminal Ready - - - - DSR - Data Set Ready - - - - DCD - Data Carrier Detect - - - - SG - Signal Ground - - - - RTS - Request to Send - - - - CTS - Clear to Send - - - -
+ + + + Acronyms + Names + + + + + + RD + Received Data + + + + TD + Transmitted Data + + + + DTR + Data Terminal Ready + + + + DSR + Data Set Ready + + + + DCD + Data Carrier Detect + + + + SG + Signal Ground + + + + RTS + Request to Send + + + + CTS + Clear to Send + + + + DB-25 to DB-25 Null-Modem Cable @@ -494,13 +492,13 @@ constructing a cable, make sure it will fit the ports on the terminal and on the &os; system. - Most terminals have DB-25 ports. Personal computers may - have DB-25 or DB-9 - ports. A multiport serial card may have - RJ-12 or RJ-45/ ports. - See the documentation that accompanied the hardware for - specifications on the kind of port or visually verify the type - of port. + Most terminals have DB-25 ports. + Personal computers may have DB-25 or + DB-9 ports. A multiport serial card may + have RJ-12 or RJ-45/ + ports. See the documentation that accompanied the hardware + for specifications on the kind of port or visually verify the + type of port.In &os;, each serial port is accessed through an entry in /dev. There are two different kinds of @@ -516,10 +514,10 @@ /dev/ttyu0 to refer to the terminal. If the terminal is on the second serial port (COM2), use - /dev/ttyu1, and so forth. Generally, the call-in port is used - for terminals. Call-in ports require that the serial line - assert the Data Carrier Detect - signal to work correctly. + /dev/ttyu1, and so forth. Generally, + the call-in port is used for terminals. Call-in ports + require that the serial line assert the Data + Carrier Detect signal to work correctly. @@ -527,17 +525,17 @@ /dev/cuauN on &os; versions 10.x and higher and /dev/cuadN - on &os; versions 9.x and lower. - Call-out ports are usually not used for terminals, but are - used for modems. The call-out port can be used if the - serial cable or the terminal does not support the Data Carrier Detect - signal. + on &os; versions 9.x and lower. Call-out ports are + usually not used for terminals, but are used for modems. + The call-out port can be used if the serial cable or the + terminal does not support the Data Carrier + Detect signal. - &os; also provides initialization - devices - (/dev/ttyuN.init and + &os; also provides initialization devices + (/dev/ttyuN.init + and /dev/cuauN.init or /dev/cuadN.init) @@ -553,9 +551,9 @@ RTS/CTS signaling for flow control. The locking devices are used to lock flags on ports to prevent users or programs changing certain parameters. Refer to - &man.termios.4;, &man.sio.4;, and &man.stty.1; for - information on terminal settings, locking and initializing - devices, and setting terminal options, respectively. + &man.termios.4;, &man.sio.4;, and &man.stty.1; for information + on terminal settings, locking and initializing devices, and + setting terminal options, respectively. @@ -564,12 +562,11 @@ By default, &os; supports four serial ports which are commonly known as COM1, COM2, COM3, and - COM4. &os; also supports - dumb multi-port serial interface cards, such as - the BocaBoard 1008 and 2016, as well as more intelligent - multi-port cards such as those made by Digiboard. However, - the default kernel only looks for the - standard COM ports. + COM4. &os; also supports dumb multi-port + serial interface cards, such as the BocaBoard 1008 and 2016, + as well as more intelligent multi-port cards such as those + made by Digiboard. However, the default kernel only looks for + the standard COM ports. To see if the system recognizes the serial ports, look for system boot messages that start with @@ -577,17 +574,18 @@ &prompt.root; grep uart /var/run/dmesg.boot - If the system does not recognize all of the needed serial ports, - additional entries can be added to + If the system does not recognize all of the needed serial + ports, additional entries can be added to /boot/device.hints. This file already contains hint.uart.0.* entries for - COM1 and hint.uart.1.* entries - for COM2. When adding a port entry for - COM3 use - 0x3E8, and for COM4 use - 0x2E8. Common IRQ addresses - are 5 for COM3 and - 9 for COM4. + COM1 and hint.uart.1.* + entries for COM2. When adding a port + entry for COM3 use + 0x3E8, and for COM4 + use 0x2E8. Common IRQ + addresses are 5 for + COM3 and 9 for + COM4. ttyu cuau @@ -599,20 +597,19 @@ &prompt.root; stty -a -f /dev/ttyu1 - System-wide initialization of serial devices is - controlled by /etc/rc.d/serial. This - file affects the default settings of serial devices. To - change the settings for a device, use stty. - By default, the changed settings - are in effect until the device is closed and when the device is - reopened, it goes back to the default set. To permanently - change the default set, open and adjust the settings of the - initialization device. For example, to turn on - mode, 8 bit communication, and - flow control for + System-wide initialization of serial devices is controlled + by /etc/rc.d/serial. This file affects + the default settings of serial devices. To change the + settings for a device, use stty. By + default, the changed settings are in effect until the device + is closed and when the device is reopened, it goes back to the + default set. To permanently change the default set, open and + adjust the settings of the initialization device. For + example, to turn on mode, 8 bit + communication, and flow control for ttyu5, type: - &prompt.root; stty -f /dev/ttyu5.init clocal cs8 ixon ixoff + &prompt.root; stty -f /dev/ttyu5.init clocal cs8 ixon ixoff rc files @@ -620,15 +617,15 @@ To prevent certain settings from being changed by an - application, make adjustments to the locking - device. For example, to lock the speed of - ttyu5 to 57600 bps, type: - - &prompt.root; stty -f /dev/ttyu5.lock 57600 - - Now, any application that opens - ttyu5 and tries to change the speed - of the port will be stuck with 57600 bps. + application, make adjustments to the locking device. For + example, to lock the speed of ttyu5 to + 57600 bps, type: + + &prompt.root; stty -f /dev/ttyu5.lock 57600 + + Now, any application that opens ttyu5 + and tries to change the speed of the port will be stuck with + 57600 bps. @@ -761,10 +758,10 @@ Terminal ConfigurationThis section describes how to configure a &os; system to - enable a login session on a serial terminal. It assumes that the - system recognizes the serial port to which the - terminal is connected and that the terminal is - connected with the correct cable. + enable a login session on a serial terminal. It assumes that + the system recognizes the serial port to which the terminal is + connected and that the terminal is connected with the correct + cable.In &os;, init reads /etc/ttys and starts a @@ -774,132 +771,128 @@ program. The ports on the &os; system which allow logins are listed in /etc/ttys. For example, the first virtual console, ttyv0, has an - entry in this file, allowing logins on the console. This - file also contains entries for the other virtual consoles, - serial ports, and pseudo-ttys. For a hardwired terminal, - the serial port's /dev entry is listed - without the /dev part. For example, + entry in this file, allowing logins on the console. This file + also contains entries for the other virtual consoles, serial + ports, and pseudo-ttys. For a hardwired terminal, the serial + port's /dev entry is listed without the + /dev part. For example, /dev/ttyv0 is listed as ttyv0. - The default - /etc/ttys configures support for the first - four serial ports, ttyu0 through - ttyu3: + The default /etc/ttys configures + support for the first four serial ports, + ttyu0 through + ttyu3: - ttyu0 "/usr/libexec/getty std.9600" dialup off secure + ttyu0 "/usr/libexec/getty std.9600" dialup off secure ttyu1 "/usr/libexec/getty std.9600" dialup off secure ttyu2 "/usr/libexec/getty std.9600" dialup off secure ttyu3 "/usr/libexec/getty std.9600" dialup off secure - When attaching a terminal to - one of those ports, modify the default entry to set the - required speed and terminal type, to turn the device - on and, if needed, to change the port's - secure setting. If the terminal is - connected to another port, add an entry for the port. - - configures two - terminals in /etc/ttys. The first - entry configures a Wyse-50 - connected to COM2. The second entry - configures an old computer running - Procomm terminal software - emulating a VT-100 terminal. The computer is connected - to the sixth serial port on - a multi-port serial card. - - - Configuring Terminal Entries + When attaching a terminal to one of those ports, modify + the default entry to set the required speed and terminal type, + to turn the device on and, if needed, to + change the port's secure setting. If the + terminal is connected to another port, add an entry for the + port. + + configures two terminals in + /etc/ttys. The first entry configures a + Wyse-50 connected to COM2. The second + entry configures an old computer running + Procomm terminal software emulating + a VT-100 terminal. The computer is connected to the sixth + serial port on a multi-port serial card. + + + Configuring Terminal Entries - ttyu1 "/usr/libexec/getty std.38400" wy50 on insecure + ttyu1 "/usr/libexec/getty std.38400" wy50 on insecure ttyu5 "/usr/libexec/getty std.19200" vt100 on insecure - - - The first field specifies the device name of - the serial terminal. - - - - The second field tells - getty to initialize and open the - line, set the line speed, prompt for a user name, and - then execute the login program. The optional - getty type configures - characteristics on the terminal line, like - bps rate and parity. The available - getty types are listed in - /etc/gettytab. In - almost all cases, the getty types that start with - std will work for hardwired - terminals as these entries ignore parity. There is - a std entry for each - bps rate from 110 to 115200. Refer to - &man.gettytab.5; for more information. - - When setting the getty - type, make sure to match - the communications settings used by the terminal. For - this example, the Wyse-50 uses no parity and - connects at 38400 bps. The computer uses no - parity and connects at 19200 bps. - - - - The third field is the type of terminal. For dial-up ports, - unknown or - dialup is typically used since - users may dial up with practically any type of - terminal or software. Since the terminal type does - not change for hardwired terminals, a real terminal - type from /etc/termcap can be specified. - For this example, the Wyse-50 uses the real - terminal type while the computer running - Procomm is set to - emulate a VT-100. - - - - The fourth field specifies if the port should be - enabled. To enable logins on this port, this - field must be set to on. - - - - The final field is used to specify whether the - port is secure. Marking a port as - secure means that it is trusted - enough to allow root to login from that - port. Insecure ports do not allow root logins. On an - insecure port, users must login from unprivileged - accounts and then use su or a similar - mechanism to gain superuser privileges, as described - in . For security reasons, - it is recommended to change this setting to - insecure. - - - - - After making any changes to - /etc/ttys, send a SIGHUP (hangup) - signal to the init process to force it to - re-read its configuration file: - - &prompt.root; kill -HUP 1 - - Since init is always the first process - run on a system, it always has a process - ID of 1. - - If everything is set up correctly, all cables are in - place, and the terminals are powered up, a - getty process should now be running on each - terminal and login prompts should be available on each - terminal. + + + The first field specifies the device name of the + serial terminal. + + + + The second field tells getty to + initialize and open the line, set the line speed, prompt + for a user name, and then execute the + login program. The optional + getty type configures + characteristics on the terminal line, like + bps rate and parity. The available + getty types are listed in + /etc/gettytab. In almost all + cases, the getty types that start with + std will work for hardwired terminals + as these entries ignore parity. There is a + std entry for each + bps rate from 110 to 115200. Refer + to &man.gettytab.5; for more information. + + When setting the getty type, make sure to match the + communications settings used by the terminal. For this + example, the Wyse-50 uses no parity and connects at + 38400 bps. The computer uses no parity and + connects at 19200 bps. + + + + The third field is the type of terminal. For + dial-up ports, unknown or + dialup is typically used since users + may dial up with practically any type of terminal or + software. Since the terminal type does not change for + hardwired terminals, a real terminal type from + /etc/termcap can be specified. For + this example, the Wyse-50 uses the real terminal type + while the computer running + Procomm is set to emulate a + VT-100. + + + + The fourth field specifies if the port should be + enabled. To enable logins on this port, this field must + be set to on. + + + + The final field is used to specify whether the port + is secure. Marking a port as secure + means that it is trusted enough to allow root to login from that + port. Insecure ports do not allow root logins. On an + insecure port, users must login from unprivileged + accounts and then use su or a similar + mechanism to gain superuser privileges, as described in + . For security + reasons, it is recommended to change this setting to + insecure. + + + + + After making any changes to + /etc/ttys, send a SIGHUP (hangup) signal + to the init process to force it to re-read + its configuration file: + + &prompt.root; kill -HUP 1 + + Since init is always the first process + run on a system, it always has a process ID + of 1. + + If everything is set up correctly, all cables are in + place, and the terminals are powered up, a + getty process should now be running on each + terminal and login prompts should be available on each + terminal. @@ -916,8 +909,8 @@ ttyu5 "/usr/libexec/getty std.19200" emulation software on the correct serial port. Make sure the cable is connected firmly to both the - terminal and the &os; computer. Make sure it is the - right kind of cable. + terminal and the &os; computer. Make sure it is the right + kind of cable. Make sure the terminal and &os; agree on the bps rate and parity settings. For a video @@ -926,11 +919,11 @@ ttyu5 "/usr/libexec/getty std.19200" sure paper and ink are in good supply. Use ps to make sure that a - getty process is - running and serving the terminal. For example, - the following listing shows that a getty is - running on the second serial port, ttyu1, - and is using the std.38400 entry in + getty process is running and serving the + terminal. For example, the following listing shows that a + getty is running on the second serial port, + ttyu1, and is using the + std.38400 entry in /etc/gettytab: &prompt.root; ps -axww|grep ttyu @@ -996,37 +989,40 @@ ttyu5 "/usr/libexec/getty std.19200" dial-in service - Configuring a &os; system for dial-in service is similar - to configuring terminals, except that modems are used instead of + Configuring a &os; system for dial-in service is similar to + configuring terminals, except that modems are used instead of terminal devices. &os; supports both external and internal modems. - External modems are more convenient because - they often can be configured via parameters - stored in non-volatile RAM and they usually provide lighted - indicators that display the state of important RS-232 signals, - indicating whether the modem is operating properly. - - Internal modems usually lack non-volatile RAM, so their - configuration may be limited to setting DIP switches. If the - internal modem has any signal indicator lights, they are - difficult to view when the system's cover is in place. + External modems are more convenient because they often can + be configured via parameters stored in non-volatile + RAM and they usually provide lighted + indicators that display the state of important + RS-232 signals, indicating whether the modem + is operating properly. + + Internal modems usually lack non-volatile + RAM, so their configuration may be limited to + setting DIP switches. If the internal modem + has any signal indicator lights, they are difficult to view when + the system's cover is in place. modem When using an external modem, a proper cable is needed. A - standard RS-232C serial cable should suffice. + standard RS-232C serial cable should + suffice. &os; needs the RTS and - CTS signals for flow control at speeds - above 2400 bps, 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 a login session does not go away - when the line hangs up, there may be a problem with the - cable. Refer to for more - information about these signals. + CTS signals for flow control at speeds above + 2400 bps, 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 a login session does not go away when the line + hangs up, there may be a problem with the cable. Refer to for more information about these + signals. Like other &unix;-like operating systems, &os; uses the hardware signals to find out when a call has been answered or a @@ -1034,24 +1030,24 @@ ttyu5 "/usr/libexec/getty std.19200" call. &os; avoids sending commands to the modem or watching for status reports from the modem. - &os; supports the NS8250, - NS16450, NS16550, and - NS16550A-based 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 devices prevent the use of the 16-character buffer, so use - 16550A devices if possible. Because single-character-buffer - devices require more work by the operating system than the - 16-character-buffer devices, 16550A-based serial interface - cards are preferred. If the system has many active serial - ports or will have a heavy load, 16550A-based cards are better - for low-error-rate communications. - - The rest of this section demonstrates how to configure a - modem to receive incoming connections, how to communicate - with the modem, and offers some troubleshooting tips. + &os; supports the NS8250, + NS16450, NS16550, and + NS16550A-based 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 devices prevent the use + of the 16-character buffer, so use 16550A devices if possible. + Because single-character-buffer devices require more work by the + operating system than the 16-character-buffer devices, + 16550A-based serial interface cards are preferred. If the + system has many active serial ports or will have a heavy load, + 16550A-based cards are better for low-error-rate + communications. + + The rest of this section demonstrates how to configure a + modem to receive incoming connections, how to communicate with + the modem, and offers some troubleshooting tips. Modem Configuration @@ -1060,79 +1056,72 @@ ttyu5 "/usr/libexec/getty std.19200" As with terminals, init spawns a getty process for each configured serial port used for dial-in connections. When a user dials the - modem's line and the modems connect, - the Carrier Detect signal is reported by - the modem. The kernel notices that the carrier has been - detected and instructs getty to open the - port and display a + modem's line and the modems connect, the Carrier + Detect signal is reported by the modem. The kernel + notices that the carrier has been detected and instructs + getty to open the port and display a login: prompt at the specified initial line speed. In a typical configuration, if garbage characters are - received, usually due to the modem's connection speed - being different than the configured speed, - getty tries adjusting the line speeds until - it receives reasonable characters. After the user enters their login name, - getty executes - login, which completes the login process - by asking for the user's password and then starting the user's - shell. + received, usually due to the modem's connection speed being + different than the configured speed, getty + tries adjusting the line speeds until it receives reasonable + characters. After the user enters their login name, + getty executes login, + which completes the login process by asking for the user's + password and then starting the user's shell. /usr/bin/login There are two schools of thought regarding dial-up modems. - One confiuration method is to set the modems and - systems so that no matter at what speed a remote user dials - in, the dial-in 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 + One confiuration method is to set the modems and systems so + that no matter at what speed a remote user dials in, the + dial-in 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 second method is to configure the RS-232 interface - to vary its speed based on the remote user's connection speed. - Because + The second method is to configure the + RS-232 interface to vary its speed based on + the remote user's connection speed. Because getty does not understand any particular - modem's connection speed reporting, it - gives a login: message at an initial speed - and watches the characters that come back in response. If the - user sees junk, they should press - Enter until they see a recognizable prompt. - If the data rates do not match, getty sees - anything the user types as junk, tries - the next speed, and gives the login: prompt - again. This procedure normally only takes a keystroke or two - before the user sees a good prompt. This login sequence does - not look as clean as the locked-speed method, - but a user on a low-speed connection should receive better - interactive response from full-screen programs. - - When locking a modem's data communications rate at a - particular speed, no changes to - /etc/gettytab should be needed. - However, for a matching-speed - configuration, additional entries may be required in - order to define the speeds to use - for the modem. This example configures a - 14.4 Kbps modem with a top interface speed of - 19.2 Kbps using 8-bit, no parity connections. It - configures getty to start the - communications rate for a V.32bis connection at - 19.2 Kbps, then cycles - through 9600 bps, 2400 bps, - 1200 bps, 300 bps, and back to 19.2 Kbps. - Communications rate cycling is implemented with the - nx= (next table) - capability. Each line uses a - tc= (table continuation) - entry to pick up the rest of the - settings for a particular data rate. + modem's connection speed reporting, it gives a + login: message at an initial speed and + watches the characters that come back in response. If the + user sees junk, they should press Enter until + they see a recognizable prompt. If the data rates do not + match, getty sees anything the user types + as junk, tries the next speed, and gives the + login: prompt again. This procedure normally + only takes a keystroke or two before the user sees a good + prompt. This login sequence does not look as clean as the + locked-speed method, but a user on a low-speed connection + should receive better interactive response from full-screen + programs. + + When locking a modem's data communications rate at a + particular speed, no changes to + /etc/gettytab should be needed. However, + for a matching-speed configuration, additional entries may be + required in order to define the speeds to use for the modem. + This example configures a 14.4 Kbps modem with a top + interface speed of 19.2 Kbps using 8-bit, no parity + connections. It configures getty to start + the communications rate for a V.32bis connection at + 19.2 Kbps, then cycles through 9600 bps, + 2400 bps, 1200 bps, 300 bps, and back to + 19.2 Kbps. Communications rate cycling is implemented + with the nx= (next table) capability. Each + line uses a tc= (table continuation) entry + to pick up the rest of the settings for a particular data + rate. - # + # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ @@ -1146,11 +1135,11 @@ up|V9600|High Speed Modem at 9600,8-bit: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: - For a 28.8 Kbps modem, or to take advantage of - compression on a 14.4 Kbps modem, use a higher - communications rate, as seen in this example: + For a 28.8 Kbps modem, or to take advantage of + compression on a 14.4 Kbps modem, use a higher + communications rate, as seen in this example: - # + # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kbps # @@ -1165,70 +1154,65 @@ vp|VH9600|Very High Speed Modem at 9600, vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: - For a slow CPU or a heavily loaded system without - 16550A-based serial ports, this configuration may produce - sio - silo errors at 57.6 Kbps. - - - /etc/ttys - - - The configuration of /etc/ttys - is similar to , - but a different - argument is passed to getty and - dialup is used for the terminal type. - Replace - xxx with the process - init will run on the device: - - ttyu0 "/usr/libexec/getty xxx" dialup on - - The dialup terminal type can be - changed. For example, setting vt102 as the - default terminal type allows users to use VT102 emulation on - their remote systems. - - For a locked-speed configuration, specify the speed with - a valid type listed in - /etc/gettytab. - This example is for a modem whose port speed is locked at - 19.2 Kbps: - - ttyu0 "/usr/libexec/getty std.19200" dialup on - - In a matching-speed configuration, the - entry needs to reference the - appropriate beginning auto-baud entry in - /etc/gettytab. To continue the example - for a matching-speed modem that - starts at 19.2 Kbps, use this entry: - - ttyu0 "/usr/libexec/getty V19200" dialup on - - After editing /etc/ttys, wait until - the modem is properly configured and - connected before signaling init: - - &prompt.root; kill -HUP 1 - - - rc files - rc.serial - - - High-speed modems, like V.32, - V.32bis, and V.34 modems, - use hardware (RTS/CTS) flow - control. Use stty to set the - hardware flow control flag for the modem - port. This example sets the - crtscts flag on - COM2's dial-in and dial-out - initialization devices: + For a slow CPU or a heavily loaded + system without 16550A-based serial ports, this configuration + may produce sio + silo errors at 57.6 Kbps. + + + /etc/ttys + + + The configuration of /etc/ttys is + similar to , but a different + argument is passed to getty and + dialup is used for the terminal type. + Replace xxx with the process + init will run on the device: + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***