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!linus!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c,net.bugs.4bsd
Subject: Re: code and comments disagreeing (4.[23]BSD TCP code)
Message-ID: <3278@sun.uucp>
Date: Sun, 23-Feb-86 06:10:37 EST
Article-I.D.: sun.3278
Posted: Sun Feb 23 06:10:37 1986
Date-Received: Wed, 26-Feb-86 04:25:45 EST
References: <376@mcgill-vision.UUCP>
Followup-To: net.bugs.4bsd
Organization: Sun Microsystems, Inc.
Lines: 27
Xref: linus net.lang.c:7409 net.bugs.4bsd:1671

> 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)