delorie.com/archives/browse.cgi | search |
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> |
MIME-Version: | 1.0 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |