manes@dasys1.UUCP (Steve Manes) (09/21/87)
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 about sending a break if they ain't at the default speed of the modem. They'll probably think instead that they called a very noisy line, hang up and never call back. Thinking briefly about this, I don't think it would be THAT hard to write a program that sits on the comm port waiting for the Hayes (I know... it won't be nondenominational) CONNECT xxxx string. Then it would set stty and exec 'getty'. After the tty user hangs up it would send the Hayes an ATZ to reset it to a known default. I suspect, however, that it can't be this easy so, unless anyone has a front-end that will do reliable baud sensing and they wish to share it, does anyone have any insight into why this idea won't work? +---------------------------------------------------------------------------+ | Steve Manes (NYC) Roxy Recorders, Inc. (audio) | | UUCP: !{ihnp4|uunet}!{pur-ee|iuvax}!bsu-cs!zoo-hq!magpie!manes | | Magpie BBS Development (UNIX/MSDOS): 212-420-0527 | +---------------------------------------------------------------------------+
paul@devon.UUCP (Paul Sutcliffe Jr.) (09/22/87)
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 > about sending a break if they ain't at the default speed of the modem. > They'll probably think instead that they called a very noisy line, hang > up and never call back. Check the owners manual to your modem. Some newer models (mine, for instance; a MultiTech MT224EH) allow the baud rate over the phone line to be different from the baud rate at the RS-232 (between the modem and the CPU). If your modem does this, then your solution is simple. 1) Set the modem up so that it allows auto-sensing of the baud rate in answer mode, but always uses one baud rate (ie 2400) between it and the CPU. For the MultiTech, this means entering two commands: AT$BA0 and AT$SB2400 2) Create a gettydefs line that "cycles to itself". Of course, the baud rate in the gettydefs line must match that of the modem. 3) Enable the port. There is one small side-effect to this solution. If, let's say, you have your modem speaking at 2400 baud to the CPU, and a person logs on at 300 or 1200 baud, the modem will handle the speed conversion. But, since the modem is speaking at 2400 baud to the CPU, a "stty" command will show the line as "speed 2400". This may confuse novice users. As an aside, I understand that the BSD getty has an "autobaud" feature that responds to carriage-returns to sync-up to a baud rate. This may have been a local feature of the system I saw it on. Oh yeah, the disclaimer: "I have no affiliation with MultiTech except as both a satisfied customer and an authorized dealer." - paul -- Paul Sutcliffe, Jr. UUCP (smart): paul@devon.UUCP UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/23/87)
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 ... interesting idea about modems ... |As an aside, I understand that the BSD getty has an "autobaud" feature |that responds to carriage-returns to sync-up to a baud rate. This may |have been a local feature of the system I saw it on. There's no reason to limit this to BSD. If the port speed is higher than the line speed, a return will cause a framing error (ie break) and change the speed. For example: my BBS answers at 2400 baud. By pressing return you can cycle through the speeds down to the slowest. Then you need a hardware break to get back to the high speed. I use a cycle of 2400-2400-1200-300 to insure that line noise doesn't "downshift" the port at connect time. This works very well. I do the same thing on my system at work. I sent most of this right to Steve, but there seems to be general interest, so I'll repeat it here. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
guy%gorodish@Sun.COM (Guy Harris) (09/24/87)
> |As an aside, I understand that the BSD getty has an "autobaud" feature > |that responds to carriage-returns to sync-up to a baud rate. This may > |have been a local feature of the system I saw it on. > > There's no reason to limit this to BSD. If the port speed is higher than > the line speed, a return will cause a framing error (ie break) and > change the speed. For a lot of users, there *is* a reason; they don't have source to "getty", so they can't add "autobauding" to their "getty". Most if not all versions of "getty", including the 4.[23]BSD one, can be configured to cycle between speeds if they see a break. The 4.3BSD one, however, has a separate feature wherein the user is supposed to type a CR and "getty" looks at the character it received in order to guess at what baud rate it was transmitted. This is called "autobauding" because the computer automatically figures out what the right baud rate is; you don't have to manually cycle through a set of baud rates. A comment in the code states that it's written for the Micom 600 port selector. The entry in the supplied "gettytab" for auto-bauding lines sets the speed to 2400 baud. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
elg@usl (Eric Lee Green) (09/29/87)
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..."
john@chinet.UUCP (John Mundt) (10/04/87)
In article <267@usl> elg@usl (Eric Lee Green) writes: >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.] >-- >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..." I hacked getty to wait on CR's sent to it before it output anything, and it works fine. The only problem, of course, is getting the users to bang away at the return key until the modem cycles to the right speed. Not to hard to program, since you just put it in a loop where it listens for two characters and if neither are carriage returns, it moves to the next speed. The important part is to keep getty from outputting the login message until the right speed has been established. Failure to do this tends to lock the receiving terminal because it interprets the incoming garbage as being legitimate screen control codes. My WYSE50 is especially guilty of this. John Mundt Teachers Aide, Inc. !ihnp4!chinet!teachad!fred --------------------------- My opinions reflect that of the company 'cause I *OWN* it!
hedrick@topaz.rutgers.edu.UUCP (10/04/87)
I don't recall anyone mentioning that 4.3's getty seems to have code in it to detect the speed automatically based on how a CR gets mangled. It claims to be able to detect speeds from 300 to 9600. The particular patterns may depend upon how the modems are set and the serial controller used, but on every machine we have tried, the pattern is consistent for the given machine. Similar schemes have worked for us on the DEC-20, Pyramid (BSD), and on our Cisco terminal servers. I can't swear that the 4.3 code works, since our dialups are all on terminal servers now, but as of a couple of years ago the Pyramid getty autobauded correctly, and they seem to be using the 4.3 code.