From owner-freebsd-net@FreeBSD.ORG Fri May 28 09:30:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C717106567F for ; Fri, 28 May 2010 09:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4E38FC1D for ; Fri, 28 May 2010 09:30:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4S9U7OG018105 for ; Fri, 28 May 2010 09:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4S9U7UJ018100; Fri, 28 May 2010 09:30:07 GMT (envelope-from gnats) Date: Fri, 28 May 2010 09:30:07 GMT Message-Id: <201005280930.o4S9U7UJ018100@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mikolaj Golub Cc: Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mikolaj Golub List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:30:07 -0000 The following reply was made to PR kern/146845; it has been noted by GNATS. From: Mikolaj Golub To: "Lavrentiev\, Anton \(NIH\/NLM\/NCBI\) \[C\]" Cc: "Robert N. M. Watson" , freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by peer) wrongly Date: Fri, 28 May 2010 12:26:33 +0300 On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: LA> IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET LA> blindly and w/o distinguishing the situation when the remote end closes the LA> connection prematurely (i.e. before acknowledging all data written from the LA> local end) -- and that qualifies for the true "connection reset by peer" LA> from close()... I am not very familiar with the socket/tcp code but it looks for me that it might not make any difference. I can be wrong here but the situation you have described as true "connection reset by peer" seems to have the following path in the code: soclose() -> sodisconnect() -> tcp_usr_disconnect() -> tcp_disconnect() But tcp_disconnect() does not return error, so we will not have ECONNRESET error in any case. May be you have a good test suite to reproduce this situation? :-) -- Mikolaj Golub