From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 18:23:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00E416A419 for ; Fri, 20 Jul 2007 18:23:34 +0000 (UTC) (envelope-from prvs=julian=714f3ef81@ironport.com) Received: from c60-outbound.ironport.com (c60-outbound.ironport.com [63.251.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id AF95E13C48E for ; Fri, 20 Jul 2007 18:23:34 +0000 (UTC) (envelope-from prvs=julian=714f3ef81@ironport.com) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by c60-outbound.ironport.com with ESMTP; 20 Jul 2007 10:54:45 -0700 Message-ID: <46A0F706.6020701@ironport.com> Date: Fri, 20 Jul 2007 10:55:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> <469F91F8.1010406@elischer.org> <469F9258.1070500@elischer.org> <20070720072227.GD4053@void.codelabs.ru> In-Reply-To: <20070720072227.GD4053@void.codelabs.ru> Content-Type: multipart/mixed; boundary="------------050007080702000501050000" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2007 18:23:34 -0000 This is a multi-part message in MIME format. --------------050007080702000501050000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Julian, good day. > > Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote: > >> replying to myself.. the comment in the code in question said: >> >> /*-----------------------------------------------------------------*/ >> >>> /** if the elaborateTCPFin option is set, keeps the socket open >>> * and drains it until the other side closes it. Solves a problem >>> * with IE spewing extra client data to a Linux socket, then reporting >>> * an error in response a TCP reset (rather than FIN) from Linux */ >>> >> which is EXACTLY the problem I was seeing :-) >> > > I assume that you're talking about Squid code? > no this is a proprietary cache program.. > Do you think that FreeBSD TCP/IP stack should also do something > about this problem? The situation where one side closes the > descriptor while other it still trying to push the data is legal: > for example, one side invokes close() but some data from other side > is in transit, so we will see some unneccessary FIN packets. Or > you believe that fixing this is irrelevant? > I think that the possible courses of action are: 1/ Ignore further incoming data, but ACK it. (this is basically what the userland code does in this case) 2/ Stop ACKing the data, and let the other end time out. 3/ Send a RST --------------050007080702000501050000--