From owner-freebsd-net Thu Feb 8 10:31:59 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 C73B137B6AA for ; Thu, 8 Feb 2001 10:31:40 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f18IWd120580; Thu, 8 Feb 2001 12:32:39 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Feb 2001 12:32:39 -0600 From: Jonathan Lemon To: Archie Cobbs Cc: Jonathan Lemon , net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010208123239.P650@prism.flugsvamp.com> References: <200102081701.f18H1Vp17229@prism.flugsvamp.com> <200102081812.KAA56568@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200102081812.KAA56568@curve.dellroad.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote: > 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. Yes, I looked at sendmail, ftpd, sshd, telnetd, inetd, and apache. Only apache does the right thing in this case. All the other applications either: 1. handle the error from accept() in some form (which may include terminating the application), or 2. blindly use the returned sockname. So in sendmail's case, it currently does: t = accept(.., (struct sockaddr *)&RealHostAddr, &lotherend); .... p = hostnamebyanyaddr(&RealHostAddr); which will proabably coredump since it dereferences a NULL pointer. I'd think that at least having sendmail close/reopen the listen socket will result in slightly more robust behavior. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message