Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Mar 2001 19:55:57 +0100
From:      Arjan.deVet@adv.iae.nl (Arjan de Vet)
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>
In-Reply-To: <Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org>
References:  <200102080524.VAA54629@curve.dellroad.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In article
<Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> 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              <Arjan.deVet@adv.iae.nl>
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 <wietse@porcupine.org>
Date: Wed, 7 Mar 2001 10:26:22 -0500 (EST)
Cc: Arjan de Vet <list.postfix.users@adv.iae.nl>, 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              <Arjan.deVet@adv.iae.nl>
> > 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010307195557.A22189>