Path: utzoo!utgpu!watmath!clyde!att!osu-cis!!rutgers!ucsd!ucbvax!snark.UUCP!eric
From: e...@snark.UUCP (EricS.Raymond)
Newsgroups: comp.dcom.modems
Subject: Microport 3.0e and the Telebit Trailblazer
Date: 16 Dec 88 23:31:00 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 207

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

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 &F Q6 S51=4 S52=2 S53=3 S54=3 S55=3 S58=2 S66=1 S92=1 S95=2

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:

	#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

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:                       CompuServe: [72037,2306]
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.