From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 20:09:48 2011 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 815FE1065675 for ; Sun, 23 Jan 2011 20:09:48 +0000 (UTC) (envelope-from prvs=100478bcf4=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1963B8FC18 for ; Sun, 23 Jan 2011 20:09:47 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 20:09:32 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 20:09:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012042848.msg for ; Sun, 23 Jan 2011 20:09:32 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=100478bcf4=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: References: <3037495B413A48AE9BCDF7C567ED2A8D@multiplay.co.uk> Date: Sun, 23 Jan 2011 20:09:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: getpeername returning ENOTCONN for a connected socket 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: Sun, 23 Jan 2011 20:09:48 -0000 ----- Original Message ----- From: "Steven Hartland" ... > Now given no previous errors from either connect, send or recv > if the connection has been terminated by the other end, which > tcpdump shows its has (RST), I would expect to get ECONNRESET > from getpeername and not ENOTCONN. > > The only case I would expect ENOTCONN is if either no connect > call had been made or if it was unsuccessful. > > Am I missing something here, is ENOTCONN and expected result > from a previously connected socket with no other indication > of error? After doing some more digging the issue may be in sys/kern/uipc_syscalls.c: kern_getpeername where it checks against so_state for SS_ISCONNECTED which can of course be true if the socket was never connected as well as if the socket has been reset by the peer. Should the following code: if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) { error = ENOTCONN; goto done; } become something like: if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) { if ((so->so_state & SS_ISDISCONNECTED) == 0) { error = ECONNRESET; } else { error = ENOTCONN; } goto done; } This would obviously report ECONNRESET for shutdown sockets as well as sockets reset by the peer, but I cant see an easy way to distinguish between these two cases without adding a new state value specifically for reset. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.