UUCP [ultrix] guru needed!

[George Robbins]

In article <1176 at cbmvax.cbmvax.cbm.UUCP> grr at 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 at seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)