Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.bugs.uucp Subject: Re: 4.2 uucp bug? Message-ID: <2403@sun.uucp> Date: Tue, 9-Jul-85 21:38:04 EDT Article-I.D.: sun.2403 Posted: Tue Jul 9 21:38:04 1985 Date-Received: Fri, 12-Jul-85 04:08:26 EDT References: <226@nsc-pdc.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 40 > 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