X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=pVkQITI8ScexorQwzujG/lmOcu/JVMXTmBABdM/tYCWC0Fs1U3pbu
	WoLghI7qptbUTmYGELV4zi++Upvghhkyq0KD+wrbcWlwSNn8dEVnu2sR5Ylp3wMs
	7DPuHMIJYq1N7suO797evVYX1bMLbHjDd74duCv8n7atl4bAi+glfM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=bl1uOesHbbnz1/CxYqTajliecpI=; b=emjnURRZyNx84xBI8c3FGnNXVrfm
	oGcoA76KuEDs8z+W7+o/2urxRlUsd1rLoUaXvUTpz13aXLkr0PDPzQxM7hYGv/5B
	CKXcKcfwdwfDxnYd0ugSICTqYeOPtL6VwqY0K+vz8bA3yP6s8QCJBMTH4VwslSs0
	3wXQEnwAd+calkU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-101.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2524, reserved
X-HELO:	drew.franken.de
Date:	Mon, 5 Feb 2018 21:15:11 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: RPC clnt_create() adress already in use
Message-ID:	<20180205201511.GC13050@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<59D90AF8D70E9740907BACDE2BCB520836E325EF AT RESW102 DOT resdom01 DOT local> <5b897ca4-9a7d-df90-e7a0-dbdedbd1f179 AT maxrnd DOT com> <20180205112617 DOT GB2912 AT calimero DOT vinschen DOT de> <20180205133450 DOT GJ2912 AT calimero DOT vinschen DOT de> <20180205140623 DOT GK2912 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20180205140623.GK2912@calimero.vinschen.de>
User-Agent:	Mutt/1.9.1 (2017-09-22)

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb  5 15:06, Corinna Vinschen wrote:
> On Feb  5 14:34, Corinna Vinschen wrote:
> > On Feb  5 12:26, Corinna Vinschen wrote:
> > > To reiterate the problem we observe:
> > >=20
> > > - socket()
> > > - setsockopt (SO_REUSEADDR)
> > > - bind() succeeds
> > > - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
> > >=20
> > > using bindresvport in place of bind only marginally changes the
> > > situation, in particular if the second parameter is set and requests a
> > > port number !=3D 0.  What happens in that case is that bindresvport c=
alls
> > > bind with this port number and checks if bind returns EADDRINUSE.
> > >=20
> > > Only then it tries to bind other port numbers in the reserved range.
> > > But we now know that bind will never return EADDINUSE if the SO_REUSE=
ADDR
> > > socket option has been set.
> > >=20
> > > Even assuming the process calls bindresvport(sock, NULL) we may end up
> > > returning a port number already in use if the process is the only Cyg=
win
> > > process on the system.  The reason is that Cygwin uses a round robin
> > > approach which relies on having a globally shared value called
> > > last_used_bindresvport.  If the process is the only Cygwin process on
> > > the system, this information is lost after exiting the process, so the
> > > next process will start with the same start port number and bind will
> > > again fail to notice the client with EADDRINUSE.
> > >=20
> > > What potential solutions to this problem do we have?
> > >=20
> > > - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
> > >   sure bind fails.
> >=20
> > Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
> > second bind succeeding and the subsequent connect failing.  The
> > entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
> > desired on the server side apparently
> >=20
> > > - bindresvport could check every local address for being free prior
> > >   to calling bind.  However, there's a potential race here.
> > >=20
> > > - DisconnectEx?  Never tried this Winsock extension but it might be
> > >   worth a shot.
>=20
> I think I have a very simple solution for the scenario which calls
> bindresvport with port number.  Still looking for a solution for
> the second problem...

I've pushed a few patches and uploaded new developer snapshots to
https://cygwin.com/snapshots.  Please give them a try.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp4u08ACgkQ9TYGna5E
T6CgXQ/8DcpiNzVSUATpWXABNSaXLERdX7+X9cnUFSIRlBhdWL6K0xqLbLE0T64X
sCgOJ0+bB0/HItWNIG+IFiRthBF0M3SefeM2OsA2EXxsawUTcR9sFqpvWTelcjOM
jRwacGQHkUbe+e5RMlValXWzcoqKRsWMtCAj2qm4DGNjzaOIkpOA7tR4N8z2Bzlt
VKML+j14fSb7Mthuql8wKonoa5x95bbZy2uN+VlfaRWY6MQUjvHgCIRky7epII4F
xmlSPLs+yhiZp3Xg/YjYFTyEGNQByGbyaraeJym4IdeYvev0gptdDlzpRlekRfVd
0swq5oi+cTd8lefiAwDbrRBHcKomDF6dweXUU7E31UxuMIugs7yMSTjUK8auNCqY
Mzs8CUfDT3tqi7kqHgo7UN39al9UFl7m7fUu+qcbjJs1pDLkJ5yeET8PWXx28vsA
01wr7PfL0FKPiroipFm4JdsG/rf3ef4uLU5UG3NiVwmfmSCvbIwv4bpvg6qvm3Bu
kKfi52Sj5xy/GLisPVUaE2WuMBhUDhL1m8tQP7HgsBkAwDgq5v0v5s6bkdFoIyvd
3+xyOJ+c5PYWtsNP1ezPHF6astbPwjD4rGv+7i6rleePMXtsvASViBX8i8c3wajz
kgv0u+EZ9moy254RKI4sutKQMWc3TSSfZUKs+DsfjyNvFQpy/fE=
=gxTz
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--

- Raw text -