Date: Tue, 13 Feb 2001 10:19:42 +0900 From: itojun@iijlab.net 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: <6290.982027182@coconut.itojun.org> In-Reply-To: archie's message of Mon, 12 Feb 2001 16:51:48 PST. <200102130051.QAA72498@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> No, as this is the current behavior. The change will be for accept >> to return an error, on the basis that 1) most apps already do the >> wrong thing now anyway, and 2) it brings us closer to a 'standard', >> e.g.: what other systems are doing as well. > >I don't understand then. > >What is the problem with the current behavior? Is this just an >optimization or a real bug fix? I'd say it's not worth changing >if it's just an optimization, because too many things will break. >Several apps have already been pointed out. > >And what do you mean by ``most apps already do the wrong thing now''? for background (like when this happens) see previous articles on this thread. current behavior: return 0-length sockaddr. many of the existing applications assumes to get valid sockaddr to the address family of the socket (like sockaddr_in for AF_INET socket). so if they do that, they will access uninitialized memory region, die with assert(), whatever (BIND 9.1.0 dies with assert()). it is rather questionable if the kernel can return 0-length sockaddr, standard-wise, at least for connection-oriented socket. new behavior: return ECONNABORTED. SUSv2 suggests this behavior. it is much safer as accept(2) will fail so almost every application will go to error case (if you don't have error check in userland appication, that's problem in application). itojun 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?6290.982027182>