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
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
