Curious UUCP behavior (System V & Version 7)

[Guy Harris]

> We've been running a sV r1 UUCP since early February, and I have observed
> a curious interaction between out sV UUCP, and v7 UUCP's (both ours
> and other systems (e.g. 4BSD)).

> When both systems are done with whatever transfers were queued, they both
> do a `conversation complete' handshake (and log that), the sV UUCP goes
> away (and exec's uuxqt), but the v7 one hangs on for about 50 seconds,
> apparently waiting for something. The v7 UUCP does not exhibit this behavior
> when it talks to other v7 systems. Therefore I infer that sV UUCP isn't
> doing something that v7 is expecting it to do to complete a conversation.

> Does anyone know what that is?

When we first brought up the 4.2BSD UUCP up on our VAX (running 4.1BSD at
the time), we found that "uusnap" reported that several machines calling us
got a timeout.  The reason we hadn't seen this before was that other versions
of UUCP don't bother logging timeouts.  After much debugging, I found the
following (code extracted from "cntrl.c").  The big comment is the explanation
for this phenomenon.  The added "if (role == MASTER) RMESG..." made the problem
go away.

	case HUP:
		DEBUG(4, "%s\n", "HUP:");
		if (msg[1] == 'Y') {
			WMESG(HUP, YES);
			/*
			 * If you look at this code carefully, you'll see that
			 * any site, either master or slave, which receives an
			 * HY always acknowledges with an HY.  Therefore, the
			 * actual protocol is:
			 *
			 * MASTER: send H ("I've got no work, how about you?")
			 * SLAVE: send HY ("I'm ready to hang up, how about you?")
			 * MASTER: send HY ("I'm ready to hang up, let's hang up.")
			 * SLAVE: send HY (this is the one that "isn't supposed
			 *	to be there") and turn off protocol.
			 *
			 * So the master should wait for the slave's HY before
			 * turning the protocol off on its side.
			 * What should REALLY happen is that only a MASTER
			 * should send out the HY, but changing that here would
			 * not solve the problem of talking to a side which
			 * hasn't fixed this.
			 * It looks like both people doing the turnoff is OK,
			 * in that it will result in an exchange of close
			 * messages and each machine will shut down when the
			 * it gets the CLOSE message from the other machine.
			 */
			if (role == MASTER)
				RMESG(HUP, msg, 1);
			(*Turnoff)();
			Rdmsg = Imsg;
			Wrmsg = Omsg;
			return(0);
		}

HOWEVER, after we put this fix in we found that a number of systems which
we talked to (some called us, we called some) that formerly didn't get
a timeout now got one!  Some of those systems were running a rewritten-from-
scratch UUCP ("research" and "alice", I believe) which may not have had the
bug mentioned above, and didn't send the extra HY, so we waited in vain for
it.  Some of those systems ran honey danber, and I don't know whether they
have the bug or not.  Some, however, claimed to run a vanilla SV UUCP - but
every UUCP I've seen the source to (V7, 4.1BSD, S3, 4.2BSD, S5) seems to
have the exact same code for handling hangups, and should all have the
same behavior!  Either I'm missing something, or something very wierd is
going on here.

I have no idea if this is the same problem or not, but I'd certainly be
curious to find out...

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy