From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 08:26:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05D5916A4CE for ; Fri, 16 Jan 2004 08:26:34 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AF5E43D39 for ; Fri, 16 Jan 2004 08:26:22 -0800 (PST) (envelope-from kfaiczak@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Fri, 16 Jan 2004 11:26:15 -0500 Message-ID: From: Ken Faiczak To: "'freebsd-net@freebsd.org'" Date: Fri, 16 Jan 2004 11:26:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: forged tsecr giving -ve numbers in rtt calculation causing retran smit on next tick X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 16:26:34 -0000 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