Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site wlbr.UUCP Path: utzoo!linus!philabs!cmcl2!floyd!whuxle!mit-eddie!genrad!decvax!ittvax!dcdwest!sdcsvax!bmcg!cepu!trwrba!trwrb!scgvaxd!wlbr!jm From: jm@wlbr.UUCP Newsgroups: net.unix-wizards,net.bugs.uucp Subject: Re: Curious UUCP (reposting...) Message-ID: <176@wlbr.UUCP> Date: Wed, 6-Jun-84 14:33:11 EDT Article-I.D.: wlbr.176 Posted: Wed Jun 6 14:33:11 1984 Date-Received: Sat, 9-Jun-84 07:51:33 EDT References: <546@dual.UUCP> Organization: Eaton ES, Westlake Village, CA Lines: 61 [] Evidently, this didn't make it everywhere, so here it goes again... (Sorry to everyone who has seen it before) Erik Fair complains about V7 uucp timing out at shutdown when communicating with a System V uucp. The problem also occurs with 4.x systems. Having studied this problem, I offer the following detailed (and rather long winded) explanation, with some general suggestions (but no details) on how to fix it. This problem occurs because of the pk user mode emulation. cntrl() exhanges HUPY messages, then calls pkclose(), which tries to exchange M_CLOSE messages with the remote system. The problem is that, in the user mode pk routines, pkclose() does not wait for the reply from the other side. It merely tries twice (sending two control packets), then "gives up", and proceeds with the close. As a result, two packets are left in the input queue of the both hosts (this is true for all uucps that I know of). Now then, cntrl() returns to main(), which tries to exchange OO messages using imsg() and omsg(). imsg() uses the same message sync character as the pk routines. Soooooo.... imsg() sees the M_CLOSE message that pkclose() left on the line, and starts looking for a terminator (a NULL or newline, I believe), and finds it after the two M_CLOSE messages and the desired OO message, so he returns a bunch of garbage as data. No biggee, main() discards the rubbish, sends another OO message, and things go on correctly. That is why two V7 sites work OK. Now then, System V uucp has a new, improved imsg(). If he finds an imbedded sync character while receiving a message, he will reset some pointers, and start over again, throwing away the garbage. So, a System V uucp will see the FIRST OO message, and terminate without further hassle. This is fine on dialup lines, because the line will be hung up before long, and this will also terminate the V7 uucp. However, if the two are connected with a hardwire line, the V7 uucp will wait around for another OO message that will never come (until it times out). There are several ways to "fix" the problem: 1) Fix the user mode pkclose(), so that he WAITS for a response. This would really be the preferred fix, but..... 2) Fix the V7 (and 4.x) imsg() to conform to System V. (Let's see now, how many thousands of sites was that????) 3) Break the System V imsg() to conform to V7 (Yeuchhh!!!) 4) Shorten the time that main() waits for imsg() to come back with the OO message. (Blahhhhhh!!!!!!) Not having a whole lot of time to come up with a solution, I chose (2) at our site, so our hardwired systems work right. Jim Macropol {ihnp4,trwrb,vortex,scgvaxd}!wlbr!jm