From owner-freebsd-bugs  Wed Jun 25 09:50:04 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA02409
          for bugs-outgoing; Wed, 25 Jun 1997 09:50:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA02402;
          Wed, 25 Jun 1997 09:50:01 -0700 (PDT)
Date: Wed, 25 Jun 1997 09:50:01 -0700 (PDT)
Message-Id: <199706251650.JAA02402@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Subject: kern/3948: nonworking t/tcp server side
Reply-To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/3948; it has been noted by GNATS.

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: brian@firehouse.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: kern/3948: nonworking t/tcp server side
Date: Wed, 25 Jun 1997 12:45:38 -0400 (EDT)

 <<On Wed, 25 Jun 1997 04:09:20 -0400 (EDT), Brian Mitchell <brian@firehouse.net> said:
 
 > 03:48:31.553801 localhost.1056 > localhost.finger: SFP 319123411:319123420(9) 
 > win 57344 <mss 16344,nop,wscale 0,nop,nop,timestamp 48396 
 > 0,nop,nop,cc[|tcp]> (DF)
 
 > 03:48:31.555366 localhost.finger > localhost.1056: S 319212645:319212645(0) 
 > ack 319123422 win 57344 <mss 16344,nop,wscale 0,nop,nop,timestamp 48396
 > 48396,nop,nop,cc[|tcp]> (DF)
 
 You're right that this does appear to be an error, assuming that this
 is /not/ the first T/TCP connection on localhost.  I doubt that anyone
 will have the time to figure this out any time soon, since T/TCP is
 not widely used, but if you're motivated to look into it I'm certain
 any further diagnosis you can make will be helpful if the problem is
 to be eventually solved.
 
 Note that it certainly is possible for the syn-ack to get sent without
 waiting for data, but only in the particular case of the 200-ms
 delayed-ack timer firing between the acceptance of the connection and
 the server's presentation of new data to send.  (In this
 implementation, the fast timer will always force out any unsent data,
 including the return syn, if a delayed ack is pending, as in this
 case.)  However, this does not strike me as a particularly likely
 occurrence, and certainly should not occur every time unless you have
 a particularly slow machine.
 
 You might start looking for this problem at this point (in
 tcp_input.c):
                         if ((tiflags & TH_FIN) || (ti->ti_len != 0 &&
                             in_localaddr(inp->inp_faddr)))
                                 tp->t_flags |= (TF_DELACK | TF_NEEDSYN);
                         else
                                 tp->t_flags |= (TF_ACKNOW | TF_NEEDSYN);
 
 The condition in the if statement should be true; you might add some
 debugging statements around this point to see whether TF_ACKNOW is
 being set.  You could also try using the TCP debugging features (set
 SO_DEBUG and use trpt(8) on a kernel with the TCPDEBUG option); this
 should definitively tell you whether a timer is firing.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick