guy@sun.uucp (Guy Harris) (02/23/86)
> Found in our kernel code: > > /* this should be SEQ_LT; is SEQ_LEQ for BBN vax TCP only */ > (SEQ_LT(ti->ti_ack, tp->iss) || You'll be happy to know this is fixed in 4.3beta; the comment is gone (and the code uses SEQ_LEQ). However, while looking up "iss", I found a worse bug; "netinet/tcp_var.h" refers you to RFC783, which is the TFTP RFC, NOT the TCP RFC, which is RFC793. The copy of RFC793 we have is dated September 1981, not December 1981, and the sequence variables are defined on page 19, not page 21. This demonstrates how useful comments are. (From my quick reading of the code and the RFC, SEQ_LEQ seems to be correct; "tp->iss" is the sequence number on the "SYN" sent out, and the other side should ACK that SYN with the next sequence number it expects to see, which must be greater than the one it just saw.) > (gee, I wonder now, should I worry about posting "secret" code? :-) This code is not AT&T code, it's Berkeley code (and may be descended from BBN code). I don't know whether there are any trade secret restrictions on Berkeley's or BBN's TCP implementation, although since the US Federal Gummint paid for the Berkeley work (and maybe the BBN work) I tend to doubt it. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
scott@cdp.UUCP (03/01/86)
/* Written 3:10 am Feb 23, 1986 by guy@sun.UUCP in cdp:net.bugs.4bsd */
/* ---------- "Re: code and comments disagreeing (" ---------- */
> Found in our kernel code:
>
> /* this should be SEQ_LT; is SEQ_LEQ for BBN vax TCP only */
> (SEQ_LT(ti->ti_ack, tp->iss) ||
You'll be happy to know this is fixed in 4.3beta; the comment is gone (and
the code uses SEQ_LEQ). However, while looking up "iss", I found a worse
bug; "netinet/tcp_var.h" refers you to RFC783, which is the TFTP RFC, NOT
the TCP RFC, which is RFC793. The copy of RFC793 we have is dated September
1981, not December 1981, and the sequence variables are defined on page 19,
not page 21. This demonstrates how useful comments are. (From my quick
reading of the code and the RFC, SEQ_LEQ seems to be correct; "tp->iss" is
the sequence number on the "SYN" sent out, and the other side should ACK
that SYN with the next sequence number it expects to see, which must be
greater than the one it just saw.)
> (gee, I wonder now, should I worry about posting "secret" code? :-)
This code is not AT&T code, it's Berkeley code (and may be descended from
BBN code). I don't know whether there are any trade secret restrictions on
Berkeley's or BBN's TCP implementation, although since the US Federal
Gummint paid for the Berkeley work (and maybe the BBN work) I tend to doubt
it.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.arpa (yes, really)
/* End of text from cdp:net.bugs.4bsd */