From owner-freebsd-net Wed Mar 7 10:57: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from news.IAEhv.nl (news.iae.nl [212.61.26.37]) by hub.freebsd.org (Postfix) with ESMTP id F1E9537B71B for ; Wed, 7 Mar 2001 10:57:01 -0800 (PST) (envelope-from Arjan.deVet@adv.iae.nl) Received: (from uucp@localhost) by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id TAA09499 for freebsd-net@freebsd.org; Wed, 7 Mar 2001 19:57:00 +0100 (MET) Received: by adv.devet.org (Postfix, from userid 100) id 274253E15; Wed, 7 Mar 2001 19:55:57 +0100 (CET) Date: Wed, 7 Mar 2001 19:55:57 +0100 To: freebsd-net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010307195557.A22189@adv.devet.org> References: <200102080524.VAA54629@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Organization: Eindhoven, the Netherlands From: Arjan.deVet@adv.iae.nl (Arjan de Vet) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article Robert Watson wrote: >It seems that the ECONNABORTED is the "standard" way to address this >scenario; it might be an interesting exercise for someone to look at the >common application suites and see how they respond to various failure >modes in accept(). It certainly appears that BIND9 expects that. FYI, Postfix seems to have problems with the ECONNABORTED part of the change, see the mail below from postfix-users. Arjan -- Arjan de Vet, Eindhoven, The Netherlands URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl Subject: Re: errors from flush [again] In-Reply-To: <20010306234957.EE524BC06D@spike.porcupine.org> "from Wietse Venema at Mar 6, 2001 06:49:57 pm" To: Wietse Venema Date: Wed, 7 Mar 2001 10:26:22 -0500 (EST) Cc: Arjan de Vet , postfix-users@postfix.org Message-ID: <20010307152622.01B61BC070@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Postfix 20010228 is OK on FreeBSD 4.2-RELEASE. I just checked that the system behaves sanely when Postfix does connect() write() close() before the server has accept()ed the connection. Reportedly, some later FreeBSD versions introduce a race condition here. If the server accept()s the connection before the client close()s it, then the server may receive the data. If the server accept()s the connection after the client close()s it, the data is lost. In both cases, the client is told that the data was transmitted without error. This change in socket behavior breaks the Postfix flush service, and probably also breaks other parts of Postfix as well. It all depends on how quickly a server can call accept(), and thus, it all depends on how loaded a server is. This is a bad change. uname -a output: FreeBSD hades.porcupine.org 4.2-RELEASE FreeBSD 4.2-RELEASE #5: Sun Mar 4 18:58:52 EST 2001 wietse@hades.porcupine.org:/usr/src/sys/compile/GENERIC i386 Wietse Wietse Venema: > That's it. Postfix connects/writes/disconnects. The changed behavior > causes loss of data that was already written and acknowledged. > > The bad part is that there is no way for the sender to find out. > > Wietse > > Arjan de Vet: > > In article <20010306213602.11432BC06D@spike.porcupine.org> you write: > > > > >Every 100 seconds means whenever the master 'wakeup' timer goes > > >off. This means that UNIX-domain socket behavior has changed. > > > > I've looked through recent commits to socket code and this one may be > > the problem (not verified yet, it's time to go to sleep ;-): > > > > jlemon 2001/02/13 18:09:12 PST > > > > Modified files: > > sys/kern uipc_socket.c uipc_syscalls.c > > Log: > > Return ECONNABORTED from accept if connection is closed while on the > > listen queue, as well as the current behavior of a zero-length sockaddr. > > > > Obtained from: KAME > > Reviewed by: -net > > > > Revision Changes Path > > 1.88 +3 -6 src/sys/kern/uipc_socket.c > > 1.85 +15 -2 src/sys/kern/uipc_syscalls.c > > > > This change was applied on Feb 24 to FreeBSD 4.2-stable. > > > > The change in uipc_socket.c is: > > > > @@ -365,11 +365,8 @@ > > so->so_state &= ~SS_NOFDREF; > > if ((so->so_state & SS_ISDISCONNECTED) == 0) > > error = (*so->so_proto->pr_usrreqs->pru_accept)(so, > > nam); > > - else { > > - if (nam) > > - *nam = 0; > > - error = 0; > > - } > > + else > > + error = ECONNABORTED; > > splx(s); > > return (error); > > } > > > > ECONNABORTED is exactly the error I'm seeing now. > > > > >At the very least, the kernel could deliver the data that > > >is send with connect/write/disconnect. > > > > Arjan > > > > -- > > Arjan de Vet, Eindhoven, The Netherlands > > URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message