eric@snark.uu.net (Eric S. Raymond) (05/15/89)
This is revision 2 of the everything-you-always-wanted-to-know-about-the
Trailblazer-but-were-afraid-to-ask posting. It supersedes my posting
<eUTug#2jxipt=eric@snark.UUCP> of 16 Dec 88 23:29:53 GMT. I have bothered with
this revision because Telebit's documentation, while relatively quite good for
a product of this type, makes too many assumptions about what the user
already knows and can do.
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, I 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 'Blazer via kermit or cu.
To do this 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. To
use cu, you'll need a Devices file entry that
looks like
Direct tty000 - 9600 direct
and you'll invoke cu as
cu -l/dev/tty00
where tty00 should be replaced with the name of the serial port your modem is
connected to. It's possible your cu may also need an `-s 9600' option; to see
what it does as it tries to connect, use -d.
Once connected, you want to enter the following commands:
AT &F Q6 S51=4 S52=2 S53=3 S54=3 S55=3 S58=2 S66=1 S92=1 S95=2 &W &N
Note: these settings work on a System V 3.0 running on generic 80386 AT-bus
hardware with 8250-based serial ports. See the notes below for what to do about
strange machines like the T5100 or AT&T 7300.
If you enter incorrect settings, you can correct after hard-resetting the
'Blazer. Older versions have a microswitch on the back of the modem; on newer
ones, you just turn off the power, hold down the T/D switch, and power
on again. Keep T/D pressed until the 'MR' light comes on.
If the 'Blazer hangs up when you type <CR> after the above command, you
have incorrect settings; probably S53 and/or S58 are wrong. Hard-reset and
see note 3 below.
Explanation of the settings above follows:
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 important; without it, UNIX will think the modem line is active
all the time and uucico/cu/kermit may not be able to get past a deathless getty
hanging on the port (this happens on Microport 3.0e). However, on some other
configurations you can and must set S53=0; the AT&T 7300 and T5100 need this,
but the getty will be interruptible and everything should function normally.
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. If you are using 8251-based port hardware (in particular
if you are using a Toshiba T5100 or other portable with CMOS-only innards)
this may not work! See the discussion of flow control below, Note 3.
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: the promise and peril of 19200
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'. If you have kermit source it is not hard to hack it to
support 19200 -- but your serial port drivers may not be able to handle this
without clist overflow!
Some UNIXes on AT-bus machines are rumored to have problems this way
(Microport is one such). If you can use RTS/CTS handshaking (see note 3) the
modem will, effectively, do buffering for you and the problem goes away. If
you're using a smart multiport card like the ACE, also no problem. But if
you're stuck with a 16Mhz or slower processor, a dumb serial card and no
handshaking, you may lose characters at any speed above 2400(!) baud.
Note 2: catering to old slow broken modems.
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.
Note 3: handshaking considerations
8251-based ports have only one handshake line; the T5100 appears to
use this for the DSR/DTR pair. Therefore RTS/CTS handshaking won't work.
If setting S58=2 causes your 'Blazer to hang up, but you are not sure there's
an 8251 in the woodwork, try S58=1 (half-duplex RTS/CTS). Human dial-ins may
not like the effects of this setting, however.
If neither of these work, you *may* (repeat *may*) have a problem. XON/XOFF
handshaking can cause lossage as UUCP 'g' processing tries to interpret ^S/^Q.
Therefore you are stuck with S58=0, no handshaking. This is certainly OK if
the sites you talk to always use PEP or g-protocol spoofing, these modes
disable flow control anyhow.
It is alleged by the uunet people (who have one of the world's largest
collections of 'Blazers, and thus ought to know) that connections through
the 'Blazer at 1200/2400 cps work just fine with no handshaking. And I have
been using a T5100 connected this way for a couple of weeks without obvious
problems. So all of this may be a non-issue. Comments from RS-232 experts
or anyone else with solid practical knowledge are invited.
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:
00:23:respawn:/usr/lib/uucp/uugetty -r -t 60 tty00 BLAZER
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.
Note: on Microport, you want to use the M-prefixed `modem' devices and an
ordinary /etc/getty without -r and -t options.
Have fun!
--
Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
[Moderator's Note: Please address any follow-ups direct to Mr. Raymond or
to 'comp.dcom.modems' -- *not* to this Digest. It is cross-posted here as
a courtesy to people who may not ordinarily read the modem group. PT]