From owner-freebsd-net Mon Feb 12 18:34:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 15DE037B491 for ; Mon, 12 Feb 2001 18:34:30 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA93066; Mon, 12 Feb 2001 18:34:29 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id SAA73072; Mon, 12 Feb 2001 18:34:29 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102130234.SAA73072@curve.dellroad.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010212194058.A1479@prism.flugsvamp.com> "from Jonathan Lemon at Feb 12, 2001 07:40:58 pm" To: Jonathan Lemon Date: Mon, 12 Feb 2001 18:34:29 -0800 (PST) Cc: kris@obsecurity.org, net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message