mikej@cpmain.UUCP (Michael R. Johnston) (12/22/88)
I have an Altos 386/2000 running SYSV with BNU uucp. For my dial-in port
uugetty is running. I know I should be able to dial-out with cu or uucp
to another *nix box and initiate a session WITHOUT having to disable the
port. Unfortunately this does not work. When I attempt to do this
I usually get caught up in the "deadly embrace" where each machine attempts
to login to the other.
Obviously I am doing something wrong but as I look through the manual it
appears that there is no real configuration for this command. Just place it
in /etc/inittab and let 'er rip.
I called Altos on this one and their response was that uugetty was only meant
for an Altos to call another Altos running uugetty. The sad part about it
was that they were serious.
Can anyone explain why this doesn't work? Common configuration (?!) problems
with uugetty?
--
Michael R. Johnston - @NET: mikej@cpmain.uucp
...{cmcl2!phri!,uunet!}dasys1!cpmain!mikej || ...philabs!mergvax!cpmain!mikejallbery@ncoast.UUCP (Brandon S. Allbery) (12/31/88)
As quoted from <344@cpmain.UUCP> by mikej@cpmain.UUCP (Michael R. Johnston): +--------------- | Obviously I am doing something wrong but as I look through the manual it | appears that there is no real configuration for this command. Just place it | in /etc/inittab and let 'er rip. | | I called Altos on this one and their response was that uugetty was only meant | for an Altos to call another Altos running uugetty. The sad part about it | was that they were serious. +--------------- Every so often, you call Altos tech support and get a chucklehead. It hasn't happened to me recently, but it *has* happened.... (1) You MUST make sure the modems don't echo and don't return result codes. (2) The Xenix and early "Altos System V" versions of uugetty are broken. The solution to this is to upgrade, but as this is non-trivial and rather expensive if you're running Xenix, I'd use one of the Usenet replacement uugettys (like "modem", posted you-know-where...) instead. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
gene@zeno.MN.ORG (Gene H. Olson) (01/01/89)
Chances are your problems stem from one of the two problems below: 1) The ALTOS cu does not create a lockfile. It has been that way for at least 5 years, and although the problem has often been reported, ALTOS does not seem to think it is an important problem to solve. 2) Modem control doesn't work. Uugetty requires that cu can open the tty port with NDELAY, change the mode to CLOCAL, then turn off NDELAY and proceed to dial out and communicate. This screws up really bad on the ALTOS, and differently depending on the revision of the operating system, and the type of serial port you are using. As you might guess, I am quite bitter about the above. I have suffered with kludges to avoid both of these for years. My advice is to: 1) Replace cu (if you can) with a shell script that sets the lockfile, and 2) Force CD on the modem so the ALTOS never sees CD drop which is what upsets it. This is really cludgy, however experience says it *will* work *most* of the time. Gene H. Olson Smartware Consulting Minneapolis, MN gene@zeno.mn.org