Xref: utzoo unix-pc.uucp:328 comp.sys.att:10354
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!boulder!yonder!michael
From: michael@yonder.UUCP (Michael E. Haws)
Newsgroups: unix-pc.uucp,comp.sys.att
Subject: Re: my BNU uucp babbles to itself
Keywords: 3b1 unix-pc 7300   BNU HDB uucp uugetty cu   telebit trailblazer
Message-ID: <418@yonder.UUCP>
Date: 7 Sep 90 03:04:12 GMT
References: <270@hico2.UUCP>
Organization: Redstone Enterprises, Lakewood, Co
Lines: 30

In article <270@hico2.UUCP>, kak@hico2.UUCP (Kris A. Kugel) writes:
> I've just installed the HDB uucp (STORE release).
> Problem is, my uucp babbles to itself before it
> gets out a successful call.  The first try always
> fails as the modem mumbles "AT^M^M^MOK^M^M^M^MAT^M^M^MOK"
> to itself.  I know I sound like that late at night, but
> that's no excuse.  Anyhow, the first call dials,
> then the relays on the telebit start riccoshaying, and
> it hangs up just as it's getting a connection.
> 
> The second attempt always seems to connect with no trouble.
> 

I had/have a similar problem on my machine.  My theory is that uugetty 
is not getting out of the way fast enough and is echoing characters back
out the port and this screws up the initial dial or login attempt
to the site being called.  By the time the second dial comes around
uugetty has given up and the dial and login are successful.  What I 
ended up doing, and what appears to have cleaned up __MY__ uucp/cu 
problems was to remove the ECHO from the first set of flags in the 
gettydef entry.  I recently posted this to the net and asked if 
anyone knew for sure whether or not ECHO should or should not be 
in the first set of flags, but alas there was no response.  In any 
case it seemed to clean up my connections and I hope this helps in 
your case.


-- 
Michael E. Haws             "Keep the blue side up"          w - (303) 986-2370
boulder!yonder!michael                                       h - (303) 232-0628