Date: Tue, 13 Feb 2001 12:48:20 +0900 From: Jun-ichiro itojun Hagino <itojun@iijlab.net> To: Archie Cobbs <archie@dellroad.org> Cc: 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: <20010213034820.8881A7E2A@starfruit.itojun.org> In-Reply-To: archie's message of Mon, 12 Feb 2001 18:31:33 PST. <200102130231.SAA72979@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> for background (like when this happens) see previous articles >> on this thread. >> current behavior: return 0-length sockaddr. >Yeah, that is totally broken. >Hmm.. how long has this been the "current behavior" ? >ISTR at one time you would instead get the actual sockaddr of the >just-closed socket, rather than a bogus sockaddr... and that is the >behavior one would expect. No, i guess your memory is wrong (or remember something different). Before sys/kern/uipc_socket.c 1.52, 4.4BSD-based systems hanged up when: - TCP handshake is done - RST is issued before accept(2) after 1.52 to current, zero-length sockaddr is returned. none of these are correct. >> 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). >Why does SUSv2 suggest this when so many applications would break? >And they work fine doing the old behavior (returning a real sockaddr)? again, *BSD never worked right (in terms of SUSv2 definition of "right"). see Stevens "unix network programming" section I mentioned earlier in this thread. 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?20010213034820.8881A7E2A>