Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!hoptoad!academ!killer!usl!elg
From: elg@usl (Eric Lee Green)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: Baud-sensing 'getty'
Message-ID: <267@usl>
Date: Tue, 29-Sep-87 12:46:52 EDT
Article-I.D.: usl.267
Posted: Tue Sep 29 12:46:52 1987
Date-Received: Wed, 7-Oct-87 00:38:19 EDT
References: <7440@steinmetz.steinmetz.UUCP>
Organization: CACS, Univ of SW La, Lafayette, LA
Lines: 59
Xref: mnetor comp.unix.wizards:4645 comp.unix.questions:4373

in article <7440@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) says:
> In article <467@devon.UUCP> paul@devon.UUCP (Paul Sutcliffe Jr.) writes:
> |In article <1336@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes:
> |> Does anyone have, or has anyone played with writing, a getty that
> |> eliminates tty users having to cycle through gettydefs with a hardware
> |> break?  My system will soon be traveled by folks who won't have a clue
> 

[various ideas about using CRs for auto-bauding, using CRs for
 cycling thru baud rates, etc.]

Re: the constant 2400 baud connection to a modem: Well, you better
teach the i/o driver about hardware flow control, because what will
happen when you try to send 15K of data at 2400 baud, to a user who is
connected at 300 baud?! Without flow control, only 1/8th of the data
will get thru (at most!), and if you use software flow control, that
means that the user won't be able to transfer files using Xmodem
(because the ^S character, while it may not occur in a file, certainly
will occur in an Xmodem header!).

The basic problem is that "getty" doesn't understand modems. It was
written for terminals. Terminals are usually at a specific baud rate.

Here's how I've handled modems in the past:

Hayes compatibles: Hang up modem by unasserting DTR, then re-assert
DTR so the modem will start looking for a connection again. Look for
carrier, and then examine the CONNECT message to see what baud rate
we're at.

Alternately, many modems have a *HS (High Speed) line, although that's
useful only for detirmining the difference between 300 baud and 1200
baud. 

Other modems that send a connect message back at the baud rate of the
CONNECTION (Hayes modems send the message back at the baud rate of the
LAST connection): since you (should) know what the message is, you can
look at the bit pattern, and figure out what baud rate they connected
at.

Various odd-ball modems: Fairly easily handled by a configurable modem
database. 

What we need, then, is 

  1) a modem database, telling us how to answer modems, how to detect
what baud rate they're at, how to hang them up, etc., and
  2) a "getty" that understands it.

I suspect that we will see neither soon, alas, because AT&T doesn't
seem to be getting much productivity at all out of those thousands of
programmers they have working on Unix (they spend all their time
writing specifications or something?!), and Berkeley seems to be
pretty much wrapped up as far as BSD releases go...

--
Eric Green  elg@usl.CSNET       from BEYOND nowhere:
{ihnp4,cbosgd}!killer!elg,      P.O. Box 92191, Lafayette, LA 70509
{akgua,killer}!usl!elg        "there's someone in my head, but it's not me..."