joemu@nsc-pdc.UUCP (Joe Mueller) (07/09/85)
[eat me] Since I received such incredibly useful information regarding another bug I had in uucp I thought that I'd see if anyone else has seen this problem. When I look in LOGFILE I see the "OK (conversation complete)" message followed by a "TIMEOUT (machine-name)" message. It looks like our 4.2 BSD machine is missing the "OOOOO" message from the other machine. It's not a fatal problem since the transfer has already completed and it hangs up after the timeout, it's just a nusance that I'd like to remove. If I figure out the problem or someone gives me the solution and there is sufficient interest, I'll post the fix. Any leads would be greatly appreciated.
guy@sun.uucp (Guy Harris) (07/10/85)
> When I look in LOGFILE I see the "OK (conversation complete)" message > followed by a "TIMEOUT (machine-name)" message. It looks like our 4.2 BSD > machine is missing the "OOOOO" message from the other machine. Actually, this bug's existed in most versions of UUCP since the beginning of time; the 4.2BSD one is the only one (with the possible exception of honey danber) which actually bothered to report the timeout, so I guess nobody knew about it until then. The hangup sequence for UUCP is supposed to be: Master - sends H, indicating it has no more work and is ready to switch roles (if the slave has work) or hang up (if the slave has no more work either), and waits for an HY or HN from the slave Slave - if it has no work, it responds with HY and waits for an HY or HN from the master Master - reads the HY from the slave, sends an HY, turns off the protocol on its end (reverting to the initial "imsg"/"omsg" protocol), sends an OOOOO, sends another OOOOO, and waits for the slave to reply with OOOOO Slave - reads the HY from the master and shuts down the same way the master did However, when the slave reads the HY from the master, instead of shutting down immediately, it sends back *another* HY. If the "g" protocol is being used, this means that there is unacknowledged output; the slave waits for an acknowledgment which never comes. Eventually, it times out, but in the interim the master hasn't seen its OOOOO and times out also. This is somewhat timing dependent, so you may not get this sequence every time - however, the bug in the protocol is obvious. Either the slave should not send an HY when it receives the HY, or the master should expect an additional HY in response to the HY it sent. I originally implemented the second solution - it's not the "correct" solution, but it does match what most systems do. Rick Adams later implemented the first solution, and I believe 4.3BSD will have his UUCP. That is the right solution; furthermore, it made some timeouts that the second solution caused to occur (it seemed to happen either when talking to System V UUCP or honey danber UUCP, I'm not sure which) go away. Since I don't care whether the other guy gets spurious timeouts (they don't clutter my "uustat" output), I prefer that solution. Guy Harris