Date: Mon, 12 Feb 2001 20:55:06 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Archie Cobbs <archie@dellroad.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, 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> In-Reply-To: <200102130234.SAA73072@curve.dellroad.org> References: <20010212194058.A1479@prism.flugsvamp.com> <200102130234.SAA73072@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010212205506.B1479>