From owner-freebsd-bugs Fri Nov 16 18:50: 5 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0762937B405 for ; Fri, 16 Nov 2001 18:50:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id fAH2o1E49428; Fri, 16 Nov 2001 18:50:01 -0800 (PST) (envelope-from gnats) Date: Fri, 16 Nov 2001 18:50:01 -0800 (PST) Message-Id: <200111170250.fAH2o1E49428@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Matthew Emmerton" Subject: Re: kern/31746: failed connect(2) seems to cause problems with socket Reply-To: "Matthew Emmerton" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/31746; it has been noted by GNATS. From: "Matthew Emmerton" To: , Cc: Subject: Re: kern/31746: failed connect(2) seems to cause problems with socket Date: Fri, 16 Nov 2001 21:42:12 -0500 I've hacked away at this for a bit, and it seems that during the first call, something NULLs out so_pcb. This makes the COMMON_START macro (see netinet/tcp_usrreq.c) fail out with EINVAL, and since tcp_connect() uses the COMMON_START macro, any subsequent connect() will fail with EINVAL instead of ECONNREFUSED. The in_pcbdetach() and in_pcbdisconnect() routines seem to be likely culprits, and I'm currently tracking down where one of these functions may be called in error. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message