Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!cbmvax!grr From: grr@cbmvax.cbm.UUCP (George Robbins) Newsgroups: comp.unix.wizards Subject: Re: UUCP [ultrix] guru needed! Message-ID: <1181@cbmvax.cbmvax.cbm.UUCP> Date: Sat, 27-Dec-86 02:31:47 EST Article-I.D.: cbmvax.1181 Posted: Sat Dec 27 02:31:47 1986 Date-Received: Sat, 27-Dec-86 08:35:42 EST References: <4333@mit-eddie.MIT.EDU> <1269@ncc.UUCP> <1176@cbmvax.cbmvax.cbm.UUCP> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 50 Keywords: Need help with a nonfunctioning uucp... Summary: my head hurts... In article <1176@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >I'm glad other people are wondering if ultrix has uucp problems. It's easy to >convince oneself that there is some kind of problem in ultrix uucp, it's a hell >of a lot harder to prove it. Nothing like spending XMAS over a hot protocol analyzer... Anyway, it looks like Ultrix does have a problem in the protocol that makes certain kinds of errors result in no-recovery situation. ========= Here's what happens: Ultrix sends packet N. Other sends RR packet N to acknowledge. Ultrix sends a packet N+1. Packet N+1 falls in bit-bucket. (sync char gets trashed) Other times out. Other sends RR packet N to acknowledge last packet seen. Ultrix sees packet N already acknowledged - sends nothing!!! Other times out. Other sends RR packet N to acknowledge last packet seen. Ultrix sees packet N already acknowledged - sends nothing!!! . . . Other decides retry count exceeded - gives up. Ultrix times out - fatal. ========== The other system can't do anything about packet N+1 because it's never seen it. If it had and there was an error in it, it could have rejected it, but *only* if it recognizes the bad packet. Ultrix is happy because the other keeps sending it nice acknowledgment packets, even if they don't say anything new. It doesn't time out or get errors because they are such nice packets. ========== Now the kicker - as far as I can tell this is the way both Berkeley and AT&T unix play the game! It looks pretty easy to fix, but am I missing something? Just add a test in pksack that says if you get an ack for a packet already acknowledged, and you've already sent another packet, then set the retransmit flag. Well, am I confused? Am I the 91'st person to discover this problem this year? Any uu.experts out there who want to comment? -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)