Curious UUCP (reposting...)

[jm at wlbr.UUCP]

[]

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