fixed in FreeBSD by John Polstra:
Fix a bug (apparently very old) that can cause a TCP connection to
be dropped when it has an unusual traffic pattern. For full details
as well as a test case that demonstrates the failure, see the
referenced PR (FreeBSD's kern/3998).
Under certain circumstances involving the persist state, it is
possible for the receive side's tp->rcv_nxt to advance beyond its
tp->rcv_adv. This causes (tp->rcv_adv - tp->rcv_nxt) to become
negative. However, in the code affected by this fix, that difference
was interpreted as an unsigned number by max(). Since it was
negative, it was taken as a huge unsigned number. The effect was
to cause the receiver to believe that its receive window had negative
size, thereby rejecting all received segments including ACKs. As
the test case shows, this led to fruitless retransmissions and
eventually to a dropped connection. Even connections using the
loopback interface could be dropped. The fix substitutes the signed
imax() for the unsigned max() function.
Bill informs me that his research indicates this bug appeared in Reno.
unsigned character machines. So that people don't have to reverse engineer
this again:
mksyntax detects if characters are signed or not and builts a syntax
table that has a base of 129 for signed characters or 1 for unsigned
characters. This is so the largest negative signed char [-128] + the
base == 1. 0 is special and means end of file in both cases. PEOF
is -1 for the unsigned character case and -129 for the signed
character case, so that syntax[PEOF + base] == syntax[0] == CEOF
So PEOF has to be -1, but it is explicitly compared with
unsigned characters on machines where characters are unsigned.
The quick fix is to define UPEOF the (unsigned char) version of PEOF
and use that. A better fix is to always use unsigned characters
when referencing symbol table entries, but that would require
extensive changes to the shell. So to summarize
syntax[0] == CEOF, base + PEOF == 0
unsigned signed
base 1 129
PEOF -1 -129
