Path: utzoo!attcan!uunet!pmafire!uudell!sequoia!balkan!wrangler!ssbn!bill
From: bill@ssbn.WLK.COM (Bill Kennedy)
Newsgroups: comp.sys.ncr
Subject: Re: Cannot dial out on 600/3.00.01
Message-ID: <1924@ssbn.WLK.COM>
Date: 1 Dec 90 18:08:39 GMT
References: <1139@cnw01.storesys.coles.oz.au>
Reply-To: bill@ssbn.WLK.COM (Bill Kennedy)
Organization: W.L. Kennedy Jr. and Associates, Pipe Creek, TX
Lines: 44

In article <1139@cnw01.storesys.coles.oz.au> iann@cnw01.storesys.coles.oz.au (Ian Nicholls) writes:
>I've just upgraded one of our Tower 32/600's to Unix release 3.0.01, and now
>we can't dial out, using the supplied programs uucico and cu.
[ ... ]
>The problem is that as soon as cu tries to read from the modem, it fails
>with the message "lost line errno - 0", and tries the next line.  A capture
>of such an attempt is below.

I had exactly the same problem (among others) after the upgrade from Vr2 to
3.0.01, the only difference being a Telebit modem.  I believe that the problem
resides in the hpsio code rather than ther other stuff because I have a number
of new anomalies (anyone get 38.4Kbps to work?) in addition to this one.  I
did two things, one of them unique to Telebits.  Before I go into it, I also
found that there is now a considerable delay required before an indial's \r
is seen by uugetty.  I've had to have my neighbors put one or more \d delays
when a single \p delay worked with the Vr2 hpsio.

As I was watching the lost line errors I concluded that the hpsio wasn't
setting CLOCAL as fast or wasn't changing the tty structure.  All of my
Dialers scripts do something to the modem and expect nothing first.  That
would work OK but the script would fail when something _was_ expected.

>hayes	=,-,	"" \M\dAT\r\c OK\r \EATDT\T\r\c CONNECT \m\c

You might try something like
hayes	=,-,	"" \M\dATQ0 "" \dATE1 OK\r \EATDT\T\r\c CONNECT \m\c
I found that twiddling with delays before actually expecting something
helped a lot.  I also set the Telebit to keep DCD high unless the "real"
DCD dropped, then drop it for a half second.  That was more to solve a
problem with indials though.

While we're on the hpsio topic (since I suspect that's what is wrong here),
mine will not drop DTR when I kill the uugetty.  DTR does cycle properly
at the conclusion of a connection, but not on a wrong number answer or when
I kill the uugetty with signal 9.  This does allow the modem to get into
a strange state from time to time.  Has anyone seen this as well?  Is it
a bug or a feature :-)?  Any workarounds?  Any updates beyond .01?

>Ian Nicholls         Phone : +61 3 829 6088   Fax: +61 3 829 6886
>Coles/Myer Ltd.      E-mail: iann@cnw01.storesys.coles.oz.au
>L1 M11, PO Box 480, Glen Iris 3146, Australia
-- 
Bill Kennedy  usenet      {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill
              internet    bill@ssbn.WLK.COM   or attmail!ssbn!bill