From owner-freebsd-net Mon Feb 12 18:54:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 9D20437B4EC for ; Mon, 12 Feb 2001 18:54:45 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1D2t6E14468; Mon, 12 Feb 2001 20:55:06 -0600 (CST) (envelope-from jlemon) Date: Mon, 12 Feb 2001 20:55:06 -0600 From: Jonathan Lemon To: Archie Cobbs Cc: Jonathan Lemon , kris@obsecurity.org, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010212205506.B1479@prism.flugsvamp.com> References: <20010212194058.A1479@prism.flugsvamp.com> <200102130234.SAA73072@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200102130234.SAA73072@curve.dellroad.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 12, 2001 at 06:34:29PM -0800, Archie Cobbs wrote: > Jonathan Lemon writes: > > It seems to me that the odds of an application being able to correctly > > handle an error return from accept() are far greater than the odds that > > the code correctly checks 'len' upon return from accept. This, combined > > with the standard, seems to be rationale enough to make the change. > > True.. but even greater still are the chances that an application will > correctly handle accept() returning a *real* sockaddr that corresponds > to an already closed connection. Please review the earlier postings in this thread. While this would probably be nice, it isn't possible with our current internals; the sockaddr is stored in the inpcb, which is destroyed when the connection is torn down. So by the time the user gets around to calling accept, the sockaddr is long gone. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message