On Tue, 20 Jan 2004, Richard Wendland wrote:
> This does suggest Ken is seeing TSecr messed up in some other way than
> simple zeroing.
Or working from an old codebase... we'll have to wait for him to respond
to find out. KEN! KEN! WHERE ARE YOO?
> I'd expect this to be a pretty rare eve
> Hm, wasn't this accounted for in rev 1.174 / 1.107.2.31? From Matt's
> commit log:
True. My notes must have been from an older version. Sorry.
> Of course, that doesn't account for other non-zero strange values. I
> guess the timestamp code needs a lot of work. :(
This does suggest Ken is
On Fri, 16 Jan 2004, Richard Wendland wrote:
> I'd hazard a guess that you are seeing zero, not forged, TSECRs.
> Windows sets TSECR zero on SYN-ACK when it does a passive open. This is
> established Windows behaviour for several years, and there is a reading
> of RFC1323 that might justify this
> it seems there is no protection from TCP session
> mucking up the tsecr values
> in some cases [t_rxtcur] ends up as say -45000
> because the secr has been forged.
I looked into this a couple of months ago, and thought at that time
that the "max allowable REXMT value" TCPTV_REXMTMAX (64 sec
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 -45000
because the secr has been forged.
