[unix-pc.general] Hayes modem auto-bauding

gst@gnosys.svle.ma.us (Gary S. Trujillo) (10/07/90)

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

gst@gnosys.svle.ma.us (Gary S. Trujillo) (10/08/90)

In <902@gnosys.svle.ma.us> I write:

> ...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...

[ bunch of stuff about autobauding getty from mystery person deleted ]

Well, by a strange quirk of fate, a getty which does autobauding and more
has just been posted to comp.sources.misc:

| From: paul@devon.lns.pa.us (Paul Sutcliffe Jr.)
| Newsgroups: comp.sources.misc
| Subject: v15i004: Enhanced SYSV Getty/Uugetty, Ver 2.0...
| Date: 6 Oct 90 00:03:52 GMT
| Sender: allbery@uunet.UU.NET
| Organization: Devon Computer Services, Lancaster, PA

From the README file:


| 			   Getty Kit, Version 2.0
|
| 		  Copyright (c) 1989,1990, Paul Sutcliffe Jr.
| ...
|
| ----------------------------------------------------------------------------
|
|
| WHY THIS GETTY:
|
| As most people have seen, the stock getty provided on Unix/Xenix
| systems lacks many features that can be useful.  The getty included in
| this distribution adds several features that I needed on my own system,
| plus includes several "Wouldn't it be nice if ..." features I've heard
| mentioned around UseNet.
|
| Getty 2.0 trys to emulate a "standard" System V getty in every way it
| can.  For instance, it uses the SysV /etc/gettydefs file (although you
| may give it a different name).  It also uses an /etc/issue file, if one
| is present.
|
| Added features include:
|
|     +	Can be used as a normal getty, or as "uugetty" to allow
| 	bi-directional usage of modem lines.
|
|     +	Reads a "defaults" file at runtime, so that a single binary
| 	can be configured differently on individual lines.  This also
| 	allows you to change getty's behavior without recompiling.
|
|     +	Let's you specify default erase and kill characters, instead
| 	of the ancient '#' and '@' convention still used in some
| 	"modern" gettys.
|
|     +	Extensive debugging (to a log file) can be enabled at compile-
| 	time.  The command line argument to envoke debugging is an
| 	octal number -- the bit pattern determines which aspects of
| 	getty's behavior are logged.
|
|     +	Let's you specify a program other than "login" to be executed
| 	after the user name is entered.
|
|     +	(and the best for last:)  The line can be "initialized"
| 	before sending the login banner (/etc/issue) and prompt with
| 	the use of an expect/send sequence not unlike that used by the
| 	UUCP L.sys (or Systems) file.
|
|     +	(and new in version 2.0:)  The CONNECT message from the modem
| 	can be used to set the line speed; no more having to toggle
| 	the speed by sending <break>'s or CR's.
|
|
| REQUIREMENTS:
|
| Getty 2.0 should drop right in to any AT&T (System III or V) Unix
| or derivitive.  It has already been successfully installed on:
|
| 	Tandy 6000		Tandy Xenix 3.2  (Microsoft Xenix 3.0)
| 	NCR Tower 32/400	Unix SVR[23]
| 	80386 clone		SCO Xenix V/386 2.2
| 	Everex STEP 386is	ESIX SVR3.2 Rev C
| ...

I haven't tried it yet, but it sounds very nice.  If anyone gets it to
work, please let us know.

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

mhw@fithp.uucp (Marc Weinstein) (10/12/90)

From article <902@gnosys.svle.ma.us>, by gst@gnosys.svle.ma.us (Gary S. Trujillo):
> In <1990Oct3.134423.1515@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:
> 
> 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

I have finally given up, and have set my uugetty to answer at 2400 baud,
which seems to be the "preferred" speed of the Hayes Smartmodem 2400.
I told all neighbor systems to send BREAKs if they must connect at 1200
baud.

> "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-

Does this imply that the default uugetty which comes with HoneyDanber
cannot do autobaud'ing?  If this is the case, then what difference does it
make what baud rate is specified to the uugetty?  Why would such a thing
even be specified?  It sounds like the far end is going to a) connect
to the modem (i.e. the modems will be speaking at the same rate), b) send
enough BREAKs to toggle to the speed which provides a recognizable "login:"
string, and then the two systems are talking.  So, it really made no
difference WHAT baud rate the uugetty was initially set to.

I'll try getting the new getty from sources, but it sounds like if this
works, what's the point?

Marc Weinstein

rlw@ttardis.UUCP (Ron Wilson) (10/15/90)

In article <1990Oct12.034821.7146@fithp.uucp>, mhw@fithp.uucp (Marc Weinstein) writes:
>From article <902@gnosys.svle.ma.us>, by gst@gnosys.svle.ma.us (Gary S. Trujillo):
>> In <1990Oct3.134423.1515@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:
>> 
>> 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
>
>I have finally given up, and have set my uugetty to answer at 2400 baud,
>which seems to be the "preferred" speed of the Hayes Smartmodem 2400.
>I told all neighbor systems to send BREAKs if they must connect at 1200
>baud.

Another possiblity: Specify a speed fo EXTB and make sure that the the
transmit and receive clock outs on the modem are connected to the clock ins
on the RS-232 port (just use a 25 pin straight through ribbon cable).

I've done this myself - it DOES work.

BTW: outgoing calls should be placed normally using one of the "internal"
speeds.

----------------------------------------------------------------------------
About MS-DOS: "... an OS originally designed for a microprocessor that modern
                kitchen appliances would sneer at...."
                   - Dave Trowbridge, _Computer Technology Review_, Aug 90

                                     iwblsys\
rlw@ttardis	    uunet!rel.mi.org!cfctech!ttardis!rlw
                sharkey.cc.umich.edu/
    rel.mi.org is currently sick - back in 2 weeks.

gst@gnosys.svle.ma.us (Gary S. Trujillo) (10/15/90)

In <1990Oct12.034821.7146@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:

[ concerning my article about replacing uugetty ]

> Does this imply that the default uugetty which comes with HoneyDanber
> cannot do autobaud'ing?

Right.  Your modem may be able to recognize different speeds based on the
type of carrier tones presented, but neither getty or the stock HDB uugetty
know how to switch the baud rate of the serial port.

> If this is the case, then what difference does it
> make what baud rate is specified to the uugetty?

Specified to the uugetty?  Well, it shouldn't matter what speed the serial
port is initially set to, as long as it can talk to the modem, if that's
what you mean.  After recognizing a connection at a given speed, the new
uugetty should be able to change the interface speed to match that speed.

> Why would such a thing
> even be specified?  It sounds like the far end is going to a) connect
> to the modem (i.e. the modems will be speaking at the same rate), b) send
> enough BREAKs to toggle to the speed which provides a recognizable "login:"
> string, and then the two systems are talking.  So, it really made no
> difference WHAT baud rate the uugetty was initially set to.

I think you missed the point.  With the new uugetty, you shouldn't need to
send any BREAKs - ever!  The whole idea is to have the uugetty take care of
matching the interface speed to the connection speed so you don't have to
send BREAKs.

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

mhw@fithp.uucp (Marc Weinstein) (10/20/90)

From article <909@gnosys.svle.ma.us>, by gst@gnosys.svle.ma.us (Gary S. Trujillo):
> In <1990Oct12.034821.7146@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:
> 
> [ concerning my article about replacing uugetty ]
> 
> I think you missed the point.  With the new uugetty, you shouldn't need to
> send any BREAKs - ever!  The whole idea is to have the uugetty take care of
> matching the interface speed to the connection speed so you don't have to
> send BREAKs.

What's the 'new uugetty' you mention?  Is this the getty that was posted
to sources some time ago?  A five part shar?

Does your statement above imply that a) system A calls my system, b) system
A's modem looks for 1200 baud connect, my uugetty is set to 2400 baud, but
system A is able to get my modem to connect when the proper tone is sent,
c) my uugetty recognizes that the connection was made at 1200 baud and
it adjusts accordingly?  I assume this scenario requires that the modem
can auto-baud using various tones.

Marc Weinstein

gst@gnosys.svle.ma.us (Gary S. Trujillo) (10/23/90)

In <1990Oct19.233911.14507@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes:

> Does your statement above imply that a) system A calls my system, b) system
> A's modem looks for 1200 baud connect, my uugetty is set to 2400 baud, but
> system A is able to get my modem to connect when the proper tone is sent,
> c) my uugetty recognizes that the connection was made at 1200 baud and
> it adjusts accordingly?  I assume this scenario requires that the modem
> can auto-baud using various tones.

Yes, yes, yes (and yes).  I think most modems are capable of dealing with
various speed connections.  The getty merely reads the speed of the con-
nection and sets the port speed accordingly.  Actually, in this implemen-
tation, now that I've looked at the code a bit more closely, the new getty
(a uugetty, actually) invokes /etc/getty with an appropriate argument to
indicate the speed it should set the port to.

No, the getty I am referring to is not the one that was posted to comp.
sources.misc recently - I have not attempted to get it working, but I know
one UNIXpc'er who spent several hours trying (he's using vanilla UUCP), but
didn't succeed in getting it to work.

As for distribution, it's a bit sticky, since the author wants me to keep
track of who it gets sent to, in order that an improved version can be sent
later.  Extenuating circumstances make said author unable to do so directly.
If there are enough inquiries, made to me, I'll see if other arrangements for
distribution can be made.  I'm not sure I'm up for the bookkeeping of keeping
track of things right now.

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