Date: Wed, 25 Jun 1997 09:50:01 -0700 (PDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: freebsd-bugs Subject: kern/3948: nonworking t/tcp server side Message-ID: <199706251650.JAA02402@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706251650.JAA02402>