eric@uunet.uu.net (EricS.Raymond) (12/17/88)
{{{ Another special issue of the TELECOM digest. The following note }}} {{{ was in the header of issue 204. -chip }}} [Moderator's Note: This special issue of the Digest is devoted to a very lengthy article submitted by Eric Raymond discussing his recent experience with a Telebit Trailblazer 9600 baud modem, a device which many Usenet administrators feel will be the answer to increasing network congestion.] {{{ Some of us news administrators are providing enough network }}} {{{ congestion as it is. (C'mon, it's only a joke.) Sorry, couldn't }}} {{{ resist. And on to the message... }}} The good people at Telebit have contributed a Trailblazer to the HyperNews project. It arrived yesterday morning, so I spent yesterday and this morning learning my way to 'Blazer expertise. The enclosure in this posting describes in detail how to mate a Trailblazer to Microport 3.0e. I am cross-posting this to unix.wizards because, except for two details specified below, the procedure is generic to any SVr3 port and should thus be of considerable general interest. Heartfelt thanks to Mike Ballard at Telebit for the 'Blazer, and credit to Howard Leadmon (howardl@w3bffv) for having already done the hard work of tuning dialer script delays to keep uucico from timing out during the PEP handshake. After just hours of use I am convinced that the 'Blazer is a hot piece of hardware that lives up to every bit of its star billing. The command and register set is comprehensive, clean, and well-thought-out. The documentation is precise, concise, and programmer-friendly rather than the boring dumbed-down drivel that comes with too many technical products these days. And with this contribution the Telebit people have demonstrated once again that they care about the UNIX community and the USENET culture. I can't testify to this personally, but my friend Dave Moskowitz the comm expert (and one of the two co-sysops on CompuServe's UNIX forum) says that when his old company ran formal torture tests on a bunch of major-brand modems, the 'Blazer came out way ahead of the pack in robustness under real-world noisy-line conditions. Now if it just had V.32 support it'd be perfect :-). ----------------------------------------------------------------------------- Here's how to set up your system to use a Telebit Trailblazer modem for uucp, cu and kermit (almost all of this applies to the Telebit T1000 and T2000 modems as well). First, we describe how to set up dial-out use; then, how to enable dial-in. First, get one of your serial ports to talk to the Trailblazer via kermit. You'll need to `set line' to the UNIX device associated with the serial port, `set speed' to 9600, and perhaps `set parity' to N. Then you want to enter the following commands: AT &T AT &F Q6 S51=4 S52=2 S53=3 S54=3 S55=3 S58=2 S66=1 S92=1 S95=2 AT &W AT &N Explanation follows: AT &T ; Run diagnostics, just to make sure the modem is OK AT &F ; Reset to factory defaults AT Q6 ; Return result codes only on outgoing calls. AT S51=4 ; Use constant 9600bps speed to modem (but see Note 1) AT S52=2 ; Reset to configuration memory values on DTR drop. AT S53=3 ; DCD on carrier detect, DSR on when modem off-hook. AT S54=3 ; Pass BREAKs transparently. AT S55=3 ; Don't allow escape to command mode AT S58=2 ; Use hardware (RTS/CTS) flow control. AT S66=1 ; Lock CPU-to-'blazer speed at S51 value AT S92=1 ; Try PEP tones at end of autobauding sequence (see Note 2) AT S95=2 ; Enable MNP if other side wants it AT &W ; Put these parameters in the configuration memory AT &N ; Check the configuration values for correctness What you're doing is setting the modem up to use a fixed speed of 9600bps to talk to the CPU, but autobaud outgoing calls with PEP tones last (the settings of registers 51, 66, and 92 accomplish this). The Q6 command disables generation of some command responses in answer mode. The S52=2 tells the modem to reset to default values at the end of a call (this is necessary, because some of the dialer scripts will change settings). The S53=3 is critical; without it, UNIX will think the modem line is active all the time and uucico/cu/kermit won't be able to get past a deathless getty hanging on the port. S54=3 prevents the BREAKS that you put in expect/send scripts in order to force the callee to autobaud from getting intercepted by the modem. S55=3 guarantees that your modem won't be dumped into command mode by an escape sequence showing up in binary data. S58=2 enables the cleanest kind of RS232C flow control between the modem and your serial card. The significance of the S92 register is covered in Note 1 below. Finally, S95=2 enables MNP protocol checks (some dialer scripts turn this off). These settings make you back-compatible with a Hayes, so that kermit's dial command will still work through a vanilla ACU/hayes device connected to the Trailblazer port. Other cases are handled by commands in the Dialers scripts. Do *not* set S67=1! This looks logical but doesn't work. Also, you don't need to change S110 or S111 to get compression and 'g' protocol spoofing; by default, callers can select it, and the Dialer scripts will do the right things for outgoing calls. Note 1: if you're willing to give up using kermit(1) 4D (which only supports a 9600bps maximum) you can jack the CPU-to-modem speed up to 19200 (S51=5). In that case the `9600' speed fields in your Devices and Systems files should all change to `19200'. Note 2: You may well be able to run with S92=0, the default (PEP tones first). The S92=1 setting is conservative; it guarantees you compatibility with 2400bps modems that are either too dumb (so they mistake the PEP multi-carrier burst for a V.22 answer tone) or too smart (so they think it's a human voice and hang up). V.22 modems built to spec shouldn't do either. The cost of this conservatism is that 'Blazers running firmware release 2.2 or older, or with the S7 carrier wait time set to less than 60 seconds, may not be able to recognize yours; and you impose a longer handshake sequence (with increased chance of uucico timeout) on all Trailblazers. Further note: if your installation is outside the U.S.A. you may need to tweak the S90 and S91 registers, either to new default values or within the dialer scripts. See the Trailblazer documentation for details. Add the following lines to your Dialers file: ########## # Telebit Trailblazer Plus, T1000 or T2000 # # assumes Q6 X1 S51=4 S52=2 S53=3 S54=3 S55=3 S58=2 S66=1 S92=1 S95=2 in EEPROM # tb1200 =W-, "" \d\K\dATE0 OK ATS92=0S50=2S95=0DT\T CONNECT\s1200 tb2400 =W-, "" \d\K\dATE0 OK ATS92=0S50=3S95=0DT\T CONNECT\s2400 tb2400n =W-, "" \d\K\dATE0 OK ATS92=0S50=3DT\T CONNECT\s2400 tbPEP =W-, "" \d\K\dATE0 OK ATS92=0S95=0S50=255S7=60S111=30DT\T\r\n\d\d\d\d\d\d\d\d\c CONNECT\sFAST tbPEPc =W-, "" \d\K\dATE0 OK ATS92=0S95=0S50=255S7=60S110=1S111=30DT\T\r\n\d\d\d\d\d\d\d\d\c CONNECT\sFAST # The magic parts of these scripts are the delays after connection, which hold off handing control to uucico so it won't time out during the PEP negotiation. Now add the following lines to your Devices file: # --- Telebit Trailblazer/T1000/T2000 devices ------ # # Devices for access to a 'blazer on tty00 ACUTB tty00 - 9600 tbPEP ACUTBC tty00 - 9600 tbPEPc ACUTB2400 tty00 - 9600 tb2400 ACUTB2400N tty00 - 9600 tb2400n ACUTB1200 tty00 - 9600 tb1200 If you have more than one Trailblazer, just duplicate the list above once for each tty device connected to one. All your Systems file entries that are associated with any of the Trailblazer devices should have a speed field of 9600 (to match the speed in the Devices file). You set the actual speed of the connection by which ACU you pick -- note that the PEP entry corresponding to ACUTB autobauds, so you can usually just use that. The ACUTBC entry may be better for mail and news feeds, as it enables data compression for up to a 2:1 cut in transmission time. Compressed PEP with g-protocol spoofing running on reasonably clean phone lines can often give your UUCP a throughput of as much as 14K text characters per second! The low-speed entries avoid throwing PEP tones at modems that may be confused by them. ACUTB2400 should fall back to 1200bps if it needs to. ACUTB2400N may be useful for Telenet MNP access. The N- and C-suffix devices request compression and MNP modes from the remote respectively. The above is designed so your ACU entry can be untouched and still work for use with the kermit dial command (which doesn't know what to do with the tb* devices). If you don't care about kermit, you can call the tbPEP device ACU. Now for dial-in access. First, you need to create appropriate gettydefs and inittab entries. First, add the following to your /etc/gettydefs file: BLAZER# B9600 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B9600 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD #login: #BLAZER (whitespace added for clarity; this must be all one line). This instructs a getty running at BLAZER speed to look for logins at 9600bps only (you can use 19200 instead if your hardware can handle it and you've set S51=5 as described above). It differs from a normal entry in that HUPCL is set (this is generally a good idea for dial-in lines). Next, add the following line or one like it to your inittab: M0:23:respawn:/etc/getty ttyM00 BLAZER # For 'Blazer on COM1, bidirectional The label `M0' and device `ttyM00' need to change if you're using the modem on a different tty. For tty01 you would use: M1:23:respawn:/etc/getty ttyM01 BLAZER # For 'Blazer on COM2, bidirectional Now do a `telinit q' from root to start the getty. Finally, use kermit or cu to tell the modem AT S0=1 &W and you're set. This instructs the Trailblazer to auto-answer on the first ring, using as little as possible of uucico's fixed 3-minute timeout. ----------------------------------------------------------------------------- There are two details in the above that may need change on a non-Microport system: 1) You may not have kermit(1). Don't panic, cu(1) or tip(1) will do as well. Make sure there is a direct-line device corresponding to the port nn that you want to hang the Trailblazer off, and do a `cu -s9600 -l/dev/ttynn'. 2) The ttyMnn devices cited in the description of the inittab file are a Microport-specific hack. Other systems will just use ttymnn, but will require the getty to be a uugetty with -r and -t options. Have fun! -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718