From owner-freebsd-net  Thu Feb  8 10:13: 7 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 7DE6837B69F
	for <net@freebsd.org>; Thu,  8 Feb 2001 10:12:48 -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 KAA61440;
	Thu, 8 Feb 2001 10:12:43 -0800 (PST)
Received: (from archie@localhost)
	by curve.dellroad.org (8.9.3/8.9.3) id KAA56568;
	Thu, 8 Feb 2001 10:12:43 -0800 (PST)
	(envelope-from archie)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200102081812.KAA56568@curve.dellroad.org>
Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after
 handshake]
In-Reply-To: <200102081701.f18H1Vp17229@prism.flugsvamp.com> "from Jonathan Lemon
 at Feb 8, 2001 11:01:31 am"
To: Jonathan Lemon <jlemon@flugsvamp.com>
Date: Thu, 8 Feb 2001 10:12:43 -0800 (PST)
Cc: 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:
> >> Jayanth did make one point that an application could assume that 
> >> the error return from accept was in regards to the listening socket
> >> instead of the new socket, so that may be a concern.
> >
> >Yes I have always assumed this to be true. If the connection is
> >already broken before I get it, why bother giving it to me??
> 
> Because the connection may be broken between the point where we've
> notified the user that there is a valid connection, and when accept
> returns.  E.g.:

It was a rhetorical question. I like Robert's suggestion to return
the socket but have the first operation on the socket fail.

If you want to positively verify the new socket you can do a
getpeername(), etc.

> I would guess that code is more likely to check for an error
> return from accept() than it is to check the return size from
> the sockaddr, so this change will proabably not result in breaking
> a large amount of code.

IMHO the app is more likely to close the listen socket and stop
accepting new connections if it gets an error from accept().

For example, from an initial scan of sendmail (daemon.c:403) if
it gets an error from accept(2) it will close the (listen) socket
and reopen it.  Sendmail is robust enough not to "break" but this
shows that if it gets an accept(2) error it assumes the problem is
with the *listening* socket, not the new socket.

-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