karish@forel.stanford.edu (Chuck Karish) (05/10/89)
[ Note changed Newsgroups: and Followup-To: headers ] In article <219@mlfarm.UUCP> ron@mlfarm.UUCP (Ronald Florence) wrote: >In using the ancient (v.7 derived) uucico supplied with SCO Xenix >386ps, version 2.2.3, we have difficulties at 2400 baud when our >uucico starts up in SLAVE mode and has to switch in the middle of the >transmission to MASTER mode. As far as I can determine, our system >does not respond correctly after the remote system sends the 'H' >signal indicating that they have no further traffic for us. Instead >of the 'HN' indicating that our system has traffic for the remote, the >remote reports in the debugging logs that it received a "backspace", >(0x8). The remote then signals that it has gotten a "bad read" and >hangs up the connection. >The problem occurs at 2400 baud with the remote (calling) system using a >Trailblazer modem. We do not have a Trailblazer modem. At 1200 baud, >with a Hayes modem on the remote, there is no problem. If we initiate >the connection in MASTER mode (i.e., we call them) there is no >problem when we call the Trailblazer. Here's what it looks line from the other end, an RT running AIX 2.2.1, with a modern (HDB) UUCP: Rmtname hpda, Role MASTER, Ifn - 5, Loginuser - root rmesg - 'P' imsg >^PPgfx^@got Pgfx wmesg 'U'g send 73 nap(10) pkgetpack: Connodata=1 rec h->cntl 73 send 61 state - [INIT code a] (1) pkgetpack: Connodata=2 rec h->cntl 61 send 53 state - [INIT code a]&[INIT code b] (3) nap(10) pkgetpack: Connodata=3 rec h->cntl 53 state - [O.K.] (10) Proto started g *** TOP *** - role=MASTER, setline - X gtwvec: dir /usr/spool/uucp/hpda insert(C.hpdaC0338) insert C.hpdaC0338 at 0 return - 8 Wfile - /usr/spool/uucp/hpda/C.hpdaC0338,Jobid = hpdaC0338 Request: mindcrf!D.mindc771f9d6 --> hpda!D.mindc771f9d6 (root) setline - S wrktype - S wmesg 'S' D.mindc771f9d6 D.mindc771f9d6 root - D.mindc771f9d6 0666 root send 210 rmesg - 'S' send 210 ASSERT ERROR (uucico) pid: 7565 (5/9-9:16:09) PKXSTART ret (0) [SCCSID: @(#)pk1.c 7.3 87/10/08 15:46:51, FILE: pk1.c, LINE: 365] Here's the uucico log file for another host we call ( VAX 11/750 running 4.3): uucp denali (5/3-11:25:41,21704,0) SUCCEEDED (call to denali ) uucp denali (5/3-11:25:47,21704,0) OK (startup) uucp denali (5/3-11:25:47,21704,0) BAD READ (expected 'H' got FAIL) uucp denali (5/3-11:25:47,21704,0) FAILED (conversation complete) uucp denali (5/9-9:25:07,7668,0) LOCKED (call to denali ) uucp denali (5/9-9:25:39,7657,0) SUCCEEDED (call to denali ) uucp denali (5/9-9:25:44,7657,0) OK (startup) karish denali denaliC25ee (5/9-9:25:44,7657,0) REQUEST (mindcrf!D.mindc7722d44 - -> denali!D.mindc7722d44 (karish)) karish denali denaliC25ee (5/9-9:25:45,7657,1) BAD READ (expected 'S' got FAIL) karish denali denaliC25ee (5/9-9:25:45,7657,1) FAILED (conversation complete) Host hpda runs HP/UX version 3.01, according to their login banner. I see the same problem calling VAXen running Ultrix and 4.3BSD, Suns running various versions of SunOS, and several other types of systems. I see the same problem whether I use a Telebit Trailblazer Plus or a MultiTech 224E to call out. The Trailblazer works OK in fast mode; I can dial out, and complete a UUCP conversation successfully. In summary, this is not a XENIX problem. If it's a generic UUCP problem, is there a generic cure? Chuck Karish {decwrl,hpda}!mindcrf!karish (415) 493-7277 karish@forel.stanford.edu
rwright@novavax.UUCP (Ronald K. Wright) (05/16/89)
In article <2170@Portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes: >[ Note changed Newsgroups: and Followup-To: headers ] > >In article <219@mlfarm.UUCP> ron@mlfarm.UUCP (Ronald Florence) wrote: >>In using the ancient (v.7 derived) uucico supplied with SCO Xenix >>386ps, version 2.2.3, we have difficulties at 2400 baud when our >>uucico starts up in SLAVE mode and has to switch in the middle of the >>transmission to MASTER mode. As far as I can determine, our system >>does not respond correctly after the remote system sends the 'H' ...edited out remainder.. I have exactly the same problem from a Hayes on Tandy Xenix to a Zenith with SCO Xenix 2.2.3. Thus I believe this is a generic problem. I do not have, but would appreciate a generic fix. -=-=-==-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- R.K. Wright | uflorida!novavax!rwright Chief Medical Examiner | uflorida!novavax!medexam!rkw Assoc.Professor of Pathology(Univ.Miami)| umbio!rwright Broward County Florida | allegra!novavax!medexam!rkw
romain@salt.pyramid.com (Romain Kang) (01/18/91)
| [...] For example, it would be REAL nice if it were able | to detect the "BUSY" return from the modem and take appropriate | action, rather than waiting 30 (60?) seconds for "ogin:" (which, | of course, never shows up). Exercising pointless pendantry, your Dialers might be tweaked to look for something like a CONNECT message. You'd still time out after MAXEXPECTIME seconds (45 in our uucp.h) though. 4.3BSD and later adds an ABORT sequence that can be used in L.sys (equivalent to Systems) or (in later versions) L-devices (roughly equivalent to Devices + Dialers), but it will only abort on a fixed string, rather than a full regular expression. For example, you can tell uucico to ABORT on "BUSY", but it will blithely continue if it sees "NO DIALTONE". | It would also be nice if we could | change the timeout time for certain waits (make it 10 seconds, for | example, rather than the default 30, but only for certain strings). 4.3BSD and later variants do this. In the Pyramid ucb universe, one could use the following entry in L-devices. (Several of these features aren't in 4.3-tahoe, but they may be in 4.3-reno.) #caller line calldev class brand chat ACU ttyi48 - 2400 null "" ATE1Q0V1 OK\r\n~4 ATS7=40 OK\r\n \ ABORT BUSY\r\n ATDT\T CONNECT\s1200\r\n~40 Notes: "Null" modem brand: Normally, there would be a compiled-in brand here, like "hayes" or "telebit"; the "null" brand allows support for any sane modem connected via asynchronous tty ports. As with HDB, chat scripts are limited. For instance, there's no way to make them change the interface speed if the modem connects at a different rate (e.g., old USR Courier 2400's). [Peter Honeyman (very) briefly considered attaching a state machine to HDB to handle these and more complicated situations, but decided the costs of changing everything would not be commensurate with the benefits.] "Expect" strings: They now do something useful if you embed backslash sequences. Also, there is a timeout specified using expect~timeout; If the first "OK" doesn't appear within 4 seconds after the first "AT" command is sent, the dial sequence will abort. Also, expect the "CONNECT 1200" message within 40 seconds after sending the dial command. "ABORT BUSY\r\n": This is what you're looking for. If the string "BUSY\r\n" is seen between this point and the end of the dial script, the call will fail. | But, is there any PD or reasonably-available source code for uucico | anywhere? We are currently using HoneyDanBer UUCP, so would like | something which is "close" to that. GNU UUCP (I forget its exact name) and other public-domain variants exist. However, I haven't heard of any of them ever getting installed at hub sites with substantial UUCP loads. In your situation, without a source license, I would stick with HDB. It's well documented (in the Nutshell handbook) and it really works. | Failing that, how about a way to communicate with H, D, or B to | ask if there is any way they could either (1) add some functionality | like this to uucico or (2) create a new version of uucico which | would allow such processing. I believe Peter has something scanning the netnoise for any vain use of his name. Reasonable suggestions have a way of getting into his hands. | Finally, if this is the WORNG (sic :-) newsgroup, I'd appreciate | pointers... comp.mail.uucp seems to be where the UUCP-knowledgeable are most likely to hang out. So much for meaningful newsgroup names... Romain -- "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson