From owner-freebsd-net@FreeBSD.ORG Thu Feb 10 21:15:42 2005 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 AB98B16A4CF for ; Thu, 10 Feb 2005 21:15:42 +0000 (GMT) Received: from ghoul.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 748B143D48 for ; Thu, 10 Feb 2005 21:15:39 +0000 (GMT) (envelope-from sam@meta.net.nz) Received: from mirage.cs.waikato.ac.nz ([130.217.250.103]) by ghoul.scms.waikato.ac.nz with esmtp (Exim 4.43) id 1CzLey-0002ay-Lx for freebsd-net@freebsd.org; Fri, 11 Feb 2005 10:15:37 +1300 Received-SPF: softfail (ghoul: transitioning domain of meta.net.nz does not designate 130.217.250.103 as permitted sender) client-ip=130.217.250.103; envelope-from=sam@meta.net.nz; helo=[130.217.250.103]; Message-ID: <420BCEF7.1080603@meta.net.nz> Date: Fri, 11 Feb 2005 10:15:35 +1300 From: Sam Jansen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041222 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: SACK problems 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: Thu, 10 Feb 2005 21:15:42 -0000 During some testing on an isolated network we have, I found some interesting behaviour from a FreeBSD 5.3 host using TCP SACK. I've detailed this problem fully at: http://www.wand.net.nz/~stj2/nsc/emu_freebsd.html PCAP traces and some screenshots from tcptrace graphs can be found at the above link to show what is happening. It looks to me like SACK blocks are being incorrectly generated in this example. I can't think of any valid reason why a SACK block would SACK from below the current ACK value to above it (which is the problem here). Thoughts, anyone? Am I just wrong here and this is valid, expected behaviour? Cheers, -- Sam Jansen sam@wand.net.nz Wand Network Research Group http://www.wand.net.nz/~stj2