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=l+clKRuP2+lXheuCfFn5phwhZOLM4iThkNlvjPSKJAjBuYZ4QHl0/
	sp6Xu1zAZi8O9yeseAzvOAlLXKcOWl9RVJ2d0F4HUVOFgnT/GjDBLzzfJruEhQ27
	gobDqrw7t2BFj04/mcvY3Wlde9nuPmEfyzBXAoi9E7X8rsmYMhJcQ0=
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=eknJ5kkwzd6M/aw/Cc744CbEUfE=; b=q5+wz338C2LhLYEU1JKaMbE4x3et
	g60D8Z88Qx5WIltWRkBE/jEZA7ALGkCq8zyVHGTDHC1eAuNc4LmM6T++Q5fRm7za
	5q71a/BsRIMNw9LmzcjqYZjnR6vryWmN5zADaxh9M2bN26ciaTnj7MOYfkehENol
	jcVno7QD2MrSmXM=
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=reserved
X-HELO: drew.franken.de
Date: Mon, 5 Feb 2018 15:06:23 +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: <20180205140623.GK2912@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="GLp9dJVi+aaipsRk"
Content-Disposition: inline
In-Reply-To: <20180205133450.GJ2912@calimero.vinschen.de>
User-Agent: Mutt/1.9.1 (2017-09-22)

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

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 cal=
ls
> > 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_REUSEAD=
DR
> > 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 Cygwin
> > 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.

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...


Corinna

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

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp4ZN8ACgkQ9TYGna5E
T6B81w/9Fd/UhMDs6gnT4/0eeVLL5Mb0ZSWXtaDvGnNoCWoQy3xHXxoDVrpZojtP
arS4vUx+94e6eEpA80+yI5TSBdlwQWHxuqjdu8lEwWWGaHKq3HdyW8uzW+Hq58X8
Z3Bxs1w9RFoMxsO1hqLdtsk9NEr5s9dYFNvWcn6PdRLzKK21BFL433F8TK0fhE8G
bvlPUKqGSesCK/GKCW0Q4uAp60cMOayah6JCyYvAHvRwz9Vka2YhqedsANH9IfyH
4XuyTvtbs0wzNqgZKdqTE3D9Fe+8EywxV8T8Pn/Xb0rIVYQucPB5fABgZRcPRaQN
x6dP9G+pmAKUioC0Xu3/4UQoO8ZPicqy1T+OS/kUjEiD51V6BrZMuC0wrFW0S3Cr
Vw8YVvfC2VaFnKbRt7wEp8rKqI8c9MLpMsOKHOJe1iQ+CswN/oFNjG4trlmT618c
4O6DZeaFtqUG9Cp8qFWimIKF1cwm8+lrz4BglInoKCHoiyn+qBrnfJPo7O5tDOAe
CC/hgjBfv5znGzFI17tpojnur5kUvh6RTqbQdLJfqUgsmHwfk+YxbdV5w7NqPahP
ONFzd7r2XteCQJobRnpU3BHdaxjtxmnxYBfkdoMJE46N0UoxK/kRa4TF196wMn84
LkggRI5muP3028bm7jpenorGLw74AtlyvyEmZFv60+W5DYmMgcc=
=jS2I
-----END PGP SIGNATURE-----

--GLp9dJVi+aaipsRk--