Re: forged tsecr giving -ve numbers in rtt calculation causing retran

From: Richard Wendland (richard_at_starburst.demon.co.uk)
Date: 01/20/04

  • Next message: niranjan_at_monsoonrain.net: "Re: PPPoE problem: "Too many LQR packets lost"" 
    To: silby@silby.com (Mike Silbersack)
Date: Tue, 20 Jan 2004 00:27:48 +0000 (GMT)

    > 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 seeing TSecr messed up in some other way than
    simple zeroing.

    I'd expect this to be a pretty rare event, and perhaps my suggestion
    that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a
    good enough solution on its own for a rare event. It should certainly
    avoid the insane -450000000 tp->t_rxtcur Ken has seen. It's simple to
    implement, does what was probably originally intended, and also protects
    from bizarre problems with non-timestamp option SRTT calculation.

    Full validation of TSecr would be nice, but perhaps excessive for
    something that should not happen. A 64 second RTO may discourage such
    strangeness :)

            Richard 

    -- 
Richard Wendland				richard@wendland.org.uk
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: niranjan_at_monsoonrain.net: "Re: PPPoE problem: "Too many LQR packets lost""