From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67723 invoked by alias); 19 Dec 2017 14:35:07 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 67713 invoked by uid 89); 19 Dec 2017 14:35:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,CYGWIN_OWNER_BODY,GIT_PATCH_2,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=connections, HX-HELO:sk:mailrel, stating, gesendet X-HELO: mailrelay.dillinger.de Received: from mailrelayb.dillinger.de (HELO mailrelay.dillinger.de) (212.184.64.29) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 14:35:03 +0000 Received: from mailrelaya2.dillinger.de (mailrelaya [192.168.175.11]) by lin254mailrelayb.dillinger.de (Postfix) with ESMTP id 64E2AA37E for ; Tue, 19 Dec 2017 15:35:01 +0100 (CET) Received: from lin275.int.shsservices.de (lin275 [172.18.32.6]) by mailrelaya2.dillinger.de (Postfix) with ESMTP id 06AB124239C for ; Tue, 19 Dec 2017 15:43:33 +0100 (CET) Received: from RESW103.resdom01.local (resw103.dillinger.de [172.18.22.103]) by lin275.int.shsservices.de (Postfix) with ESMTP id 56210F3E67 for ; Tue, 19 Dec 2017 15:35:01 +0100 (CET) Received: from RESW102.resdom01.local ([fe80::a883:3db9:4459:1159]) by RESW103.resdom01.local ([fe80::a480:c1ef:e5bb:a91b%15]) with mapi id 14.03.0279.002; Tue, 19 Dec 2017 15:35:01 +0100 From: "PAULUS, Raimund, TI-ABN" To: "'cygwin@cygwin.com'" Subject: Re: RPC clnt_create() adress already in use Date: Tue, 19 Dec 2017 16:13:00 -0000 Message-ID: <59D90AF8D70E9740907BACDE2BCB520836C7DD89@RESW102.resdom01.local> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00196.txt.bz2 Hello Mark, in my earlier tests the lib and header files for tirpc was still there from= the Cygwin-installation. I think, this could influence the results of the = tests. Therefore i removed these files. From now on i used only the downloaded fil= es from sourceforge (https://sourceforge.net/projects/libtirpc/files/libtir= pc/). I tested libtirpc-0.3.2, libtirpc-1.0.1 and libtirpc-1.0.2. The resul= ts for all releases are the same.=20 I needed the following sources: auth_none.c, auth_unix.c, authunix_prot.c, bindresvport.c, clnt_bcast.c, cl= nt_dg.c, clnt_generic.c, clnt_perror.c, clnt_vc.c, debug.c, getnetconfig.c,= getnetpath.c, mt_misc.c, rpc_callmsg.c, rpc_commondata.c, rpc_generic.c, r= pc_prot.c, rpcb_clnt.c, rpcb_prot.c, xdr.c, xdr_array.c, xdr_float.c, xdr_r= eference.c, xdr_rec.c, xdr_mem.c I had to change the following (already mentioned earlier): clnt_bcast.c=20 (because POLLRDNORM, POLLRDBAND are already defined in /usr/include/sys/pol= l.h) : --> #ifndef POLLRDNORM # define POLLRDNORM 0x040 /* Normal data may be read. */ # define POLLRDBAND 0x080 /* Priority data may be read. */ --> #endif xdr.h (typedefs where missed): #include --> typedef __uint64_t u_quad_t; --> typedef __int64_t quad_t; My compile-flags: -D_GNU_SOURCE -D__GLIBC__ -D__linux__ If i build my test program with the sources above, the behavior is the same= as with the Cygwin-libtirpc: the first RPC-connection is ok, the next call= to clnt_create() delivers the error EADDRINUSE. The test program on a Linux-box works perfectly. With "netstat -n" you can = see each connection from the client to the server creates a new pair of por= ts. On the server-side the pair is always the same (ports 111, 907). On the= client-side however the ports differ from one connection to the other. Whe= n the connections are closed the ports remain in state TIME_WAIT. After a w= hile they disappear. If the RPC-client (Cygwin) is running on a Windows-box, "netstat -n" shows = the pair of ports for the first connection. The next connection attempt (cl= nt_create()) delivers: EADDRINUSE. =20 In the sources you can see the following: clnt_create() calls the function bindresvport_sa() (in bindresvport.c). Her= e the port for the connection is determined: if (port =3D=3D 0) { port =3D (getpid() % NPORTS) + STARTPORT; } and the socket is bound to the port: res =3D bind(sd, sa, salen); If this part is executed multiple times (loop) the port is always the same.= The function bind() doesn't deliver an error (res =3D 0, maybe bind() does= n't work correctly?). Therefore the error is not detected until the call of= connect() in function clnt_vc_create() (in clnt_vc.c). But here you can n= ot correct the port.=20 I tried the following: The call of setsockopt(., SO_REUSEADDR, .) before bind() doesn't change any= thing. The error still occurs. I found 2 approaches to avoid the error: 1. Before the call to bind() set the port to 0 (port =3D 0). The following = bind() searches an unused port. 2. Set the port to 0 (port =3D 0). Do not call bind(). Later the call to co= nnect() searches an unused port. I tested the two methods and the behavior was the same as the Linux-client.= It obviously works correctly. But i'm not a network specialist and i don'= t know, if it's the best solution for the problem.=20 Subsequently I downloaded the Cygwin-sources for libtirpc-0.3.2 and libtirp= c-1.0.1. And here again, with the changes mentioned in the two approaches t= he RPC-connection works perfectly. The only difference her is: a connection= does not create a pair of ports but only a single port (netstat -n). Greetings Raimund=20 -----Urspr=FCngliche Nachricht----- Von: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] Im Auftrag vo= n Mark Geisert Gesendet: Mittwoch, 22. November 2017 22:55 An: cygwin@cygwin.com Betreff: Re: WG: RPC clnt_create() adress already in use (3rd attempt at sending this) PAULUS, Raimund, TI-ABN wrote: > Hello Mark, > > is there any news with respect to libtirpc? Very important: I need it in = Cygwin 2.5.1. I neglected to report what I found; sorry for that. The difference(s) betw= een the vanilla libtirpc 1.0.1 that you downloaded and the one supplied by = Cygwin are due to the patches applied as part of the Cygwin build. If you = have the Cygwin package's source downloaded and unpacked with 'cygport prep= ' you can find these patches in /usr/src/libtirpc-1.0.1-1.src. I noticed one of the patches is a security fix. I suspect one or more of t= hese patches are causing the difficulty you're having but I don't know enou= gh about RPC in general to set up a test environment and can't devote time = to digging further. This is as far as I can go. Apologies again for not s= tating this. Regards, ..mark -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple