Date: Thu, 10 Aug 2000 23:41:40 -0700 From: jayanth <jayanth@yahoo-inc.com> To: Guido van Rooij <guido@gvr.org> Cc: freebsd-net@FreeBSD.ORG, John Polstra <jdp@polstra.com> Subject: Re: Perhaps a TCP stack problem? Message-ID: <20000810234140.B8997@yahoo-inc.com> In-Reply-To: <20000810223937.A24172@gvr.gvr.org>; from guido@gvr.org on Thu, Aug 10, 2000 at 10:39:37PM %2B0200 References: <20000810095049.C17481@gvr.gvr.org> <XFMail.000810065353.jdp@polstra.com> <20000810223937.A24172@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
It makes sense not to update tp->t_rcvtime for invalid sequence nos.
We could always add a check to see if the sequence number
falls within the expected window and then update t_rcvtime.
In tcp_input.c we could do the following:
if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) &&
SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd))
tp->t_rcvtime = ticks;
jayanth
Guido van Rooij (guido@gvr.org) wrote:
> 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
>
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?20000810234140.B8997>