Date: Fri, 16 Jan 2004 11:26:11 -0500 From: Ken Faiczak <kfaiczak@sandvine.com> To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: forged tsecr giving -ve numbers in rtt calculation causing retran smit on next tick Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337028578AB@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
We have an application that periodically sees
the tp->t_rxtcur go to a large -ve number
it seems there is no protection from TCP session
mucking up the tsecr values
tcp_input() receives it and does (ticks - tsecr + 1)
in some cases this ends up as say -450000000
because the secr has been forged.
it then does an unsigned max(tp->t_rttmin, rtt + 2) fn
rtt is -ve but the unsigned max returns it anyway
then the TCPT_RANGESET() does the min/max compare as unsigned as well
but the min is the large -ve number which becomes a large +ve number
and the number is < this so rxtcur = the large unsigned +ve number
but since rxtcur is signed its now -ve and the retransmit timer
pops at the next tick.
options to protect against this
1. use imax() in tcp_xmit_timer
this has the effect whrn this happens of setting the
rxtcur to the max all the time
2. after process_ACK:
where it checks the TOF_TS
it check if tsecr == 0 and ignores it
we could also ignore cases where (ticks - tsecr) < 0
- though I'm unsure what happens here in the case where ticks rolls
over
I think it would just ignore the update that time and use the
t_rttime calcualtion.
any thoughts??
Ken Faiczak
kfaiczak@sandvine.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337028578AB>