Re: connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke <Christian dot Franke at t-online dot de>]

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