cpcahil@virtech.uucp (Conor P. Cahill) (01/13/90)
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.
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.
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 |
+-----------------------------------------------------------------------+cpcahil@virtech.uucp (Conor P. Cahill) (01/14/90)
Yesterday, I posted this message about uucico timeout comming too early. In article <1990Jan12.230447.2579@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > 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. Since then at least three people had told me about the following solution: add \d's to the dial string which impose a delay before the uucico timeout starts. Thanks to: uunet!nuchat!steve (Steve Nuchia) uunet!comcon!tim (Tim Brown) uunet!clark!ade (Adrian Miranda) -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
bill@ssbn.WLK.COM (Bill Kennedy) (01/15/90)
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
asv@gaboon.UUCP (Stan Voket) (01/15/90)
In article <1261@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >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 Bill- I'm interested! -- +----------------------------------------------------------------------+ | - Stan Voket, asv@gaboon - OR - ...uunet!hsi!stpstn!gaboon!asv | | Land Line: (203) 746-4489 TELEX 4996516 - | +----------------------------------------------------------------------+
pax@ankh.COM (Garry M. Paxinos) (01/15/90)
In article <1990Jan14.141325.698@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: Yesterday, I posted this message about uucico timeout comming too early. In article <1990Jan12.230447.2579@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > 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. Since then at least three people had told me about the following solution: add \d's to the dial string which impose a delay before the uucico timeout starts. A simpler one, which will also respond faster (as I sent in a message today to you...) is replace the 'CONNECT' statement (or anyother as applicable) with 'CONNECT-/c-CONNECT' . With this approach, you won't have any arbitrary amount of fixed delay, if the CONNECT happens fast you'll catch it, but you'll double you total timeout period on the slow ones. Take care, Garry. -- Internet : home - pax@ankh.ftl.fl.us work : pax@megasys.com USNail : 3868 NW 21 Ct. Coconut Creek, Fl 33066 UUCP : {gatech!uflorida!novavax, mthvax, attctc, hoptoad}!ankh!pax VoiceMail: 305-973-8478
clewis@eci386.uucp (Chris Lewis) (02/03/90)
In article <1990Jan30.210321.19646@antel.uucp> mike@antel.uucp (Michael Borza) writes: > In article <1990Jan25.003421.8130@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: > >While we are at it, I would like to see a mechanism that could be used to > >indicate what is a failure. For example following the dial sequence, if > >the string "BUSY" is received, it should indicat an immediate failure. > >I haven't yet thought out a good method for specifying it, but I would > >like to have the functionality. 4.3 BSD UUCP has a facility by which you get to specify one token to abort on in either in the L-devices chat script or the L.sys expect-send stuff. eg: machine Any ACU .... expect send ABORT BUSY expect send You could trivially add this sort of thing to Xenix dial????.c programs. > I've always preferred the way the devices file (L.devices?) in > a PD dial from somebody > on usenet. In any event, the devices file basically encoded a state > machine which was interpreted at runtime. Each line consisted of > an initial state followed by a list of trigger/state-transisition > pairs. A long time ago (84?) there was such a beast posted in net.sources (this may even predate mod.sources). Worked quite nicely, but I never saw it integrated with UUCP or CU. But it was really good for setting up cron-directed remote dials and conversations/information retrievals - especially to non-UNIX equipment. (like dataswitch statistics gathering) -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list