Date: Thu, 10 Aug 2000 22:39:37 +0200 From: Guido van Rooij <guido@gvr.org> To: freebsd-net@freebsd.org Cc: John Polstra <jdp@polstra.com> Subject: Perhaps a TCP stack problem? Message-ID: <20000810223937.A24172@gvr.gvr.org> In-Reply-To: <XFMail.000810065353.jdp@polstra.com>; from John Polstra on Thu, Aug 10, 2000 at 06:53:53AM -0700 References: <20000810095049.C17481@gvr.gvr.org> <XFMail.000810065353.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
A couple of days ago, I discovered that the cvsup server kept sending
my system ACKs where my firewall in between thought that the connection
was long gone. The firewall does have the policy to just send a RST
in response. However, the RST sent was incorrect:
22:14:52.807104 AAA.BBB.CCC.DDD.5999 > UUU.VVV.WWW.XXX.1035: . 145135143:145135144(1) ack 40231428 win 17520 (DF)
22:14:52.808313 UUU.VVV.WWW.XXX.1035 > AAA.BBB.CCC.DDD.5999: R 4254735869:4254735869(0) ack 0 win 0
(never mind why, that is not the issue). On the cvsup we see the following
tcp 0 17190 AAA.BBB.CCC.DDD.5999 UUU.VVV.WWW.XXX.1035 FIN_WAIT_1
It seems that tcp_timer.c:tcp_timer_persist() does not get into the
following if-clause (which should also be in your code):
if (tp->t_rxtshift == TCP_MAXRXTSHIFT &&
((ticks - tp->t_rcvtime) >= tcp_maxpersistidle ||
(ticks - tp->t_rcvtime) >= TCP_REXMTVAL(tp) * tcp_totbackoff)) {
tcpstat.tcps_persistdrop++;
tp = tcp_drop(tp, ETIMEDOUT);
goto out;
}
The reason for that is that after a protocol control block has been
found that match the address/port combination of the incoming RST,
the TCP stack immediately increases tp->t_rcvtime.
This on turn means that ticks - tp->t_rcvtime will never be larger
then a couple of ticks.
I am not sure but I guess that in certain cases, like if incoming packet
makes absolutely no sense given the current windows and sequence
numbers, tp->t_rcvtime should not be increased.
I am not sure what the standards have to say about this but it seems
easy to detect this kind of situation and make sure that the persist
will eventually time out. Right now it seems that a broken TCP stack
on the other side will prevend that.
-Guido
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000810223937.A24172>