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:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=cc3Qo7BjIb1zvf/SrCN7B5Uam8dl2
	Z7OLcw/kmM37mNm8evCL489o4pRhV+qDRwAhm3m03q4C6s1c6wIhmgrgpH6j0D34
	DwP7cWKrbTguJUdBkL5pd3f/eP+QeNArASNWGbHrJDtnfQCKaZw+F/sebiwKCbYt
	vsoHktr8EJce9o=
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:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=AXGLDv2YNCWesT2Z4/L0WPrPrRI=; b=hKk
	Wah/HCuDMY1CMSVK8jVsNcXbE6Z9KD9CSkZ7d9SWpI+C8fy8brk0rwH2R2MNKd23
	i7pRIw11gX1BLNIc/viH0DjIZpYkVUJdHDZcEqvQKbwDSfFCM0FxL1f00s5aYP8X
	HX7CfUHnCtoEKJskVTrJjXFW/fEXxybbXDzbJjMg=
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
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CG autolearn=ham version=3.3.1
From: Oleg Moskalenko <oleg DOT moskalenko AT citrix DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Thu, 11 Apr 2013 14:31:28 -0700
Subject: RE: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID: <031222CBCF33214AB2EB4ABA279428A30140C1ACA376@SJCPMAILBOX01.citrite.net>
References: <031222CBCF33214AB2EB4ABA279428A30140C1ACA374 AT SJCPMAILBOX01 DOT citrite DOT net> <20130411212115 DOT GA1376 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20130411212115.GA1376@ednor.casa.cgf.cx>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r3BLW9iM004380

I can write a simple test server and client programs and I'll post it here,=  in a few hours. Our existing code is just too large.

Thanks
Oleg

> 
> On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote:
> >Hi All
> >
> >I found a non-standard behavior of UDP sockets in Cygwin. Normally, people =
> do not experience it, but the communication pattern that I am going to desc=
> ribe here is often used in DTLS (actually, this is virtually the only way t= o make
> OpenSSL working with DTLS on the server side), so I suppose that wit= h the
> growing DTLS popularity people will experience the problem often.
> >
> >So this is how to reproduce the problem in "plain" UDP (without actually using
> DTLS):
> >
> >1)      Server application: open a UDP socket (socket A);
> >
> >2)      Server application: bind socket A to a local server address (say,
> 172.17.17.107:3478);
> >
> >3)      Server application: wait for a packet from a client application;
> >
> >4)      Client application: open a UDP socket (socket C);
> >
> >5)      Client application: bind socket C it to a local client address (say,
> 168.16.16.106:12345);
> >
> >6)      Client application: send a UDP packet P1 from socket C to server socket A
> (to 172.17.17.107:3478);
> >
> >7)      Server application: socket A receives the packet P1 from socket C;
> >
> >8)      Server application: create another UDP socket B;
> >
> >9)      Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket
> A (172.17.17.107:3478);
> >
> >10)   Server application: connect socket B to the remote address of socket C
> (168.16.16.106:12345) by calling connect() on the datagram socket B.
> >
> >11)   Server application: send packet P2 from socket B to socket C (to
> 168.16.16.106:12345).
> >
> >12)   Client application: on socket C, receive packet P2 from socket B (from
> 172.17.17.107:3478).
> >
> >13)   Client application: from socket C, send packet P3 to the server address
> 172.17.17.107:3478.
> >
> >14)   Server application: socket A receives the packet P3 from the client socket.
> ERROR !!!
> >
> >Step 14 is wrong: the packet P3 must be delivered to socket B, because socket
> B is "connected"
> >to the remote address 168.16.16.106:12345, but socket A  is "unconnected".
> >Both sockets (A and B) are "bound" to the same server ad= dress
> >(172.17.17.107:3478) but the connected one (socket B) must be obtaining
> packets from the remote address that it is connected to.
> >
> >This is a very essential functionality for anybody who wants to implement the
> server-side DTLS communications.
> >
> >This patterns works in any OS that I tried (all FreeBSD versions, all Linux
> versions and Solaris) but Cygwin fails, unfortunately.
> >
> >I am trying to migrate (port) our server application to Cygwin, and it stops us
> completely. It works everywhere else.
> >
> >Please take a look if this is something that can be fixed quickly.
> 
> How about a simple test case?
> 
> cgf
> 
> --
> 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