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