Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!swbatl!texbell!ssbn!bill From: bill@ssbn.WLK.COM (Bill Kennedy) Newsgroups: comp.unix.i386 Subject: Re: uucico timeout is too short Summary: work around with send-expect Keywords: uucico,uucp Message-ID: <1261@ssbn.WLK.COM> Date: 14 Jan 90 17:32:40 GMT References: <1990Jan12.230447.2579@virtech.uucp> Reply-To: bill@ssbn.WLK.COM (Bill Kennedy) Organization: W. L. Kennedy Jr. and Associates, Pipe Creek, TX Lines: 69 In article <1990Jan12.230447.2579@virtech.uucp> cpcahil@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@ssbn.WLK.COM or attmail!ssbn!bill