Date: Thu, 8 Feb 2001 12:32:39 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Archie Cobbs <archie@dellroad.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010208123239.P650@prism.flugsvamp.com> In-Reply-To: <200102081812.KAA56568@curve.dellroad.org> References: <200102081701.f18H1Vp17229@prism.flugsvamp.com> <200102081812.KAA56568@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010208123239.P650>