Xref: utzoo unix-pc.general:6244 unix-pc.uucp:349 comp.sys.att:10593 Path: utzoo!utgpu!watserv1!watmath!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: <909@gnosys.svle.ma.us> Date: 15 Oct 90 07:05:12 GMT References: <902@gnosys.svle.ma.us> <1990Oct12.034821.7146@fithp.uucp> Organization: gst's 3B1 - Somerville, Massachusetts Lines: 34 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