fair@dual.UUCP (Erik E. Fair) (05/30/84)
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?
Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA
dual!fair@Berkeley.ARPA
{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
Dual Systems Corporation, Berkeley, Californiaed@mtxinu.UUCP (05/31/84)
I've observed similar behavior between a 4.2 system and a 5.0, but it's not consistent. -- Ed Gould ucbvax!mtxinu!ed
guy@rlgvax.UUCP (Guy Harris) (05/31/84)
> 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
jm@wlbr.UUCP (06/04/84)
This message is empty.