uucico timeout is too short

[Bill Kennedy]

In article <1990Jan12.230447.2579 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:
>This is probably a general comment for HDB uucico.  But my immediate
>interest is in my 386/ix system.
>
>The timeout for uucico to use when waiting for a response should
>be configurable so that those of us who have modems that use extended
>handshaking could give it enough time to connect.  

It's aggravated even worse when you have a site with a Trailblazer that
answers PEP tones last.  If you are as remote as ssbn is, the switching
delay from end of dial to initial ring eats up valuable time too.

>Many times I sit here and listen to my modem get 95% of the way through
>it's handshake just to be killed by the uucico timeout.  This happens
>about 30 or 40 percent of the time and can be a real pain in the *ss.
>45 seconds is just not enough sometimes.

Here's what I do in the Dialers script and it works just fine:

phone-number\r\d\d\d\d\d\c CONNECT\sFAST-\c-CONNECT\sFAST-\c-CONNECT\sFAST

This tells the modem to go ahead and dial (the \r after the number) and
then delay five seconds before looking for the first expect.  If the first
expect isn't received in time, send nothing (\c) and wait again which is
the full 30 seconds you already waited, and so on.

>No, I am not asking for help.
>Yes, I am just complaining (but hoping that Interactive is out there
>     listening).
>-- 
>+-----------------------------------------------------------------------+
>| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
>| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
>+-----------------------------------------------------------------------+

You don't need Interactive for that one, you can handle it yourself
in Dialers or Systems for that matter.    There *is* a caution though.
I have seen cases where CONNECT FAST came back ECT FAST, something
swallowed CONN.   In that case the modems have DCD (the LD meter is
running) and your dialer is patiently waiting for something the modem
knows it already said.    You'll burn more than a minute of LD for
nothing.  There are two remedies for that, one for each end of the
connection.

If you set the -t timeout on getty/uugetty to something like 35 seconds
the called system will give up before you pass the minimum one minute
charge.   That's still enough time for them to retry a missed login prompt
and proceed.  With my crummy phone lines, if the caller hasn't gotten
good sync on a login prompt after 35 seconds the connection is near doomed
anyway.   The uugettys here all use -t35 so that ssbn will disconnect
before any more phone time is wasted.

The second is to choose the expect string carefully.  I only look for the
FAST, i.e. FAST-\c-FAST-\c-FAST.  Don't make it too short or you're
likely to sync on something you don't want, e.g. 00-\c-00 will sync on
300, 1200, and 2400 very nicely.  If the expect is too elaborate you
risk missing part of it and it will never repeat, if too short you might
get something you didn't want and think it was what you were looking for.

Finally, and not directly related, if you're using a Telebit with the
analog side set for autobaud and you call a PEP tones last site, the
modem will sync up at 2400 and you're hosed.  I use a separate Dialers
script for PEP last sites (ssbn has one modem that answers PEP last)
and let the DTR transition reset back to float the analog side.  I'll
be happy to mail Systems/Dialers entries to anyone who wants them or
post them if there is enough interest.
-- 
Bill Kennedy  usenet      {attctc,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill at ssbn.WLK.COM   or attmail!ssbn!bill