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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=PXeeO4Zh8WDEFpZKf9tlx5jLUbnoSkHmhdSYDeZ8Dyx
	uWEv+2AeN+eEwc3FRxEfsU+AuP6cqMxc1pALedR5priyJoA4aKf6TM8mJD7oV0P0
	ze1Pk5O2H9QxW5UIZss5Wrq7dOTA2s43WLuyrPsQ/upLT3elA5/HEd17G+3ZBric
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=M+2PI+CMaivJzVbIam3J7qAqyMM=; b=dQLBaNE1kYQzo0T9K
	/gHg6nan9JrsIiedNp4n4DnowQdj4BOEV2RqJuw7LCyeAzEMg9I8nDSmUJGhL0GI
	WckWrbjkAzfGKYztqqrYv9lU+q5zCYuCpRpPypyuXaBFI0w1vaREWQ6LBYcvFHD3
	A/4VxnrLy4vecTBRLdra+CN65M=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.3 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	mailout11.t-online.de
Message-ID:	<53FCD9EC.1080703@t-online.de>
Date:	Tue, 26 Aug 2014 21:03:08 +0200
From:	Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: connect() hangs on a listen()ing AF_UNIX socket
References:	<53F61B70 DOT 2020600 AT t-online DOT de> <20140821164402 DOT GB21065 AT calimero DOT vinschen DOT de> <53F6450C DOT 3070007 AT t-online DOT de> <20140822093923 DOT GA12878 AT calimero DOT vinschen DOT de> <53F78CB1 DOT 9080406 AT t-online DOT de> <20140822201622 DOT GM32314 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20140822201622.GM32314@calimero.vinschen.de>
X-IsSubscribed:	yes

Corinna Vinschen wrote:
> On Aug 22 20:32, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>
>>> Another potential solution might be to defer the AF_UNIX handshake to
>>> the first send/recv:
>>>
>>> Whatever the peers do, there is a certain protocol used.  That means,
>>> there's an implicit understanding who's going to do the first send and
>>> who's doing the first recv.  So, after connect/accept, both sides of the
>>> sockets go into "connected_but_handshake_missing" mode.  On the first
>>> send/recv, the handshake gets started and if it fails, send/recv
>>> return ECONNRESET.
>> Is an actual handshake really required? It would possibly be sufficient that
>> each peer sends its secret+credential and then expects a correct
>> secret+credential from the other peer before sending anything.
>>
>> After actual connect()/accept():
>>
>> send our secret+cred (should not block due to TCP queuing).
> So both peers send their credentials...
>
>> if (! nonblocking recv peer secret+cred)
>>    set_state(connected_but_secret_missing)
>> else
>>    set_state(connected)
> This will almost always result in connected_but_secret_missing.  It's
> probably ok to drop the recv attempt here entirely.

Agree.


>> Before actual send()/recv()/getpeerid():
>>
>> if (state == connected_but_secret_missing) {
>>    if (! recv peer secret+cred)
>>      abort_connection(ECONNRESET)
>>    else
>>      set_state(connected)
>> }
> Sounds like a nice idea.  We should try that.  I'm just not sure how
> much time I have left to work on this before my vaca next month.  Do you
> have fun to look into that?  We have waited so long for postfix, I guess
> a couple more weeks won't really hurt.

OK, will try that

Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll 
where the secret+cred exchange is fully disabled, postfix starts up but 
queuing of mail fails.

This is because fchmod() is called on a file rename()d after open():

fd = open("tempfile", ., 0600);
// use fd's inode number and current time to create unique "queuefile".
rename("tempfile", "queuefile");
write(fd, "SOME MAIL....", .);
fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a 
chmod("tempfile",.)?)
close(fd);

A workaround using chmod("queuefile", 0700) helped here. Then smtp 
client, smtpd server (direct or via smarthost), sendmail emulation and 
local delivery to maildir works. Running as service with uid/gid 
switching is not tested yet.

It will likely take some time to look into all these details before 
first ITP.
(Therefore let's forget the "cygcheck -m" patch for now :-).

Christian


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