Xref: utzoo unix-pc.general:6185 unix-pc.uucp:341 comp.sys.att:10544
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!mintaka!spdcc!gnosys!gst
From: gst@gnosys.svle.ma.us (Gary S. Trujillo)
Newsgroups: unix-pc.general,unix-pc.uucp,comp.sys.att
Subject: Re: Hayes modem auto-bauding
Message-ID: <902@gnosys.svle.ma.us>
Date: 7 Oct 90 00:57:16 GMT
References: <1990Oct3.134423.1515@fithp.uucp>
Organization: gst's 3B1 - Somerville, Massachusetts
Lines: 107

In <1990Oct3.134423.1515@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:

> > James Warner Adams, via Lenny Tropiano, writes:
> >
> > Note also that the modem should be set to autobaud.  The /etc/gettydefs
> > "cycle" arrangement to select the incoming baud rate is based on
> > obsolete modems which could not autobaud...

> What is meant by "should be set to autobaud?"  From the modem settings
> given above this paragraph, I see nothing which tells the modem to
> act differently wrt autobaud'ing.

I have just succeeded in setting up my Telebit T2500 to handle incoming
calls, and autobaud to boot.  The experience was not exactly a pleasant
one, since it meant a great deal of reading materials I've collected on
the subject over the past couple of years in these newsgroups, as well
as the Telebit handbook and the O'Reilly "Nutshell" thing - plus a lot
of headscratching and playing around with things.  Maybe if I can find
the time, I'll write yet another article on setting up your Trailblazer
to work with Honey-Danber UUCP.  None of the articles I've seen so far,
taken by itself, seems to be sufficient.  What the UNIXpc world needs,
IMHO, is an easy-to-understand kit sort of thing, that explains all the
details, and tells you everything you need to know, and solves as many
of the known problems as possible.  Some of the writeups come close, but
I found they all leave out some important details.  However, I should
point out that without them, I'd still be scratching my head, so I do
owe a big debt of gratitude to those giants upon whose shoulders I was
privileged to stand!

Given my experience, my conclusion is that, while you may be able to get your
modem to permit connections at different baud rates, the main problem has to
do with getting your local modem to talk to your computer at an appropriate
speed.  No modem advances can really help with this problem, so I disagree
with the statement about "obsolete modems" being the reason for needing to
use the /etc/gettydefs cycling scheme.

My impression is that the normal thing for the modem to do is to set its
"interface" speed (the baud rate between the RS-232 port of the modem and
that of the computer) to correspond to the speed at which the connection was
made, *unless* the modem can be told (as the Telebit modem can, by setting
one of its many registers to an appropriate value) to "lock" this speed at a
given rate (usually the highest rate possible, or 19.2kb for the Telebit
series, so that connections can be achieved at all rates up to and including
the locked speed).  According to Boyd Ostroff's article later in this
thread, at least some 2400 baud modems are also capable of locking the baud
rate.

I think that, unless you can lock the baud rate the modem uses to communi-
cate with the computer, regardless of the speed it's using to talk to the
modem at the other end, you have to have some way of matching the computer
interface speed to that of the modem, hence the cycling scheme provided by
/etc/gettydefs.

*However*, to further complicate matters, there are some reasons why you
might not want to lock the interface speed (I decided not to), and it *is*
possible to do real autobauding, which I define as being able to match the
speed of the user's modem with requiring her to do *anything* to tell the
remote end to try another baud rate, or some such - just dial, connect,
and get a "login:" prompt at the correct speed.  (Your modem does need to
be able to recognize and respond correctly to the various carrier tones
the remote modem which is attempting connection might put out, though.)

"How?" I can hear you saying...  Well, the trick is to replace uugetty,
which is the beast that sits there waiting for the modem to do something,
and forks a login when the right something happens.  I had the good for-
tune to run into someone at the Usenix conference back in January who had
written a replacement getty for the UNIXpc, and who kindly sent me a copy
(you know who you are! :-).  Perhaps if there's enough clamour, said person
will post it to unix-pc.sources, or will permit me to do so.  The trick it
uses is to have the modem's register S0 == 0, and it waits for a RING msg,
at which point it (uugetty) tells the modem to answer the call, and it does
a bit of register poking to figure out the speed of the connection.  I have
not looked at the code carefully, but I think this is basically how it works.
(BTW, "uugetty" comes with HDB UUCP; it replaces /etc/getty, which is what
is used by vanilla UUCP.  I think the main difference is that uugetty can
remain active on a line while it is being used for an outgoing call, while
getty has to be killed and restarted at such times, so it doesn't gobble
up characters and attempt to fork a login process, thinking that the line
activity represents a login attempt.)

Oh - about the reasons for not wanting to lock the interface speed:

	1. If the speed is locked, you can't talk to the UNIXpc on-
	   board modem (OBM), at least with the Telebit modems with
	   interface speed locked at 9600 or 19.2kb, since the modem
	   tends to shave time off the stop bits, or some such, or
	   it may have to do with the OBM mis-identifying itself as
	   being MNP-capable.  I've forgotten the exact problem, but
	   I know it is a problem.

	2. From the comments that came with the replacement uugetty--

	   The only thing that my uugetty does that the others don't is
	   to autobaud the serial port.  Instead of locking the port at
	   a high speed (eg. 19.2K), this uugetty changes the speed of
	   the port to match the speed of the incoming call.  This way
	   when you get a 2400 baud system calling you, your computer
	   knows this and doesn't go filling up the buffer in the
	   'blazer.  This is important since the remote end can't flush
	   the data in the buffer.  Try doing an ls -l on a big
	   directory ar 2400 baud and then try stopping it!

'Nuff said?

-- 
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst