Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site cuae2.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!mgnetp!hw3b!wnuxb!cuae2!heiby From: heiby@cuae2.UUCP (Ron Heiby) Newsgroups: net.micro.att Subject: Re: Help needed with Penril auto-answer/auto-dial modems on 3b2 Message-ID: <353@cuae2.UUCP> Date: Fri, 5-Jul-85 11:03:04 EDT Article-I.D.: cuae2.353 Posted: Fri Jul 5 11:03:04 1985 Date-Received: Sat, 6-Jul-85 10:44:32 EDT References: <729@pyuxqq.UUCP> <186@lzwi.UUCP> Reply-To: heiby@cuae2.UUCP (Ron Heiby) Organization: AT&T-IS, /app/eng, Lisle, IL Lines: 22 In article <186@lzwi.UUCP> psc@lzwi.UUCP (Paul S. R. Chisholm) writes: >If you specify bidirectional instead, uugetty is run on >the line. Uugetty not only knows how to step out of the way of >outgoing calls, but is a little bit smarter about smart modems. The two main things about uugetty that makes it different from ordinary getty is that A) it conforms to the same locking protocol that cu and uucico conform to, and B) it doesn't "wake up" until it receives a character (like a CR). This means that someone (or a uucico) login in must send a character before they will see a "login:" prompt. It also means that if characters are sent from the modem when a local uucico has ended and the line disconnects, uugetty will see that there are incoming characters and no current lock on the line, so it will "wake up". I believe that this is why the uugetty is supposed to be specified with a 60 second timeout and why the documentation recommends not trying to access that port for at least 60 seconds. The key words are, "little bit smarter." Part of the above is conjecture, although I believe it to be substantially correct. In short, don't worry about it. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109