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:content-type
	:content-transfer-encoding:mime-version; q=dns; s=default; b=qEl
	VcBPJSpbDydMu+4TBuhQDI9HdkfihgBgUv6GRO7NaUGixVBVC1rXF3HCm937SquA
	RXt1X9hYqKDqVPEtaxnwJKyDAd5bikewQHz+cnFtv0/KjRi26PAdUdbnBfFlA7ag
	whr0EQnyy+8Nry/sE20amZw5eCDWbThFUBh3pU/E=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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:19:25 -0700
Subject: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID: <031222CBCF33214AB2EB4ABA279428A30140C1ACA374@SJCPMAILBOX01.citrite.net>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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.

Thanks!
Oleg Moskalenko


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