delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2013/04/11/17:21:40

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=fW6x9QPUU9is+Gr1YinnvhNzKCASdy8+2VfXSLRIyOZ6rZ6h48HEy
XUVHdj5rjVf55bw6OBEkpyxvT/S/yjKXOzyoIt2+1V/Z+DaA93Eq7vMQkmktsVeO
SDTjxyOesPdNMcr5PlmIx710EHecydYjYGu0e/HmsPSfPIj/pJD+EE=
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=+L1e0TysmAiGA1o/5AL/ZGGlBQQ=; b=p/LGEObYa3M+XI0P1pPx9qVPDKEG
D6/1I/14mvVblGfcx4O+0+oleZZjQb97Z5hRefa99neFcfXnlMem1FYW/V4mB5mf
eR0mLEP5V0scL0XhSG1OzQSMCyRCE2qBXbJ/TCLCld5Y5vZiMbSOAlZr+S5mam8i
cd5s35vydm5QplA=
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=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Report-Abuse-To: abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18WB3zhGnD1X5PbzYuMMFKW
Date: Thu, 11 Apr 2013 17:21:15 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID: <20130411212115.GA1376@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <031222CBCF33214AB2EB4ABA279428A30140C1ACA374 AT SJCPMAILBOX01 DOT citrite DOT net>
MIME-Version: 1.0
In-Reply-To: <031222CBCF33214AB2EB4ABA279428A30140C1ACA374@SJCPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.20 (2009-06-14)

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019