Having problems understanding async_connect_send and async_connect_connected in lib/async_req/async_soc.c

[Richard Sharpe]

On Fri, Oct 16, 2015 at 11:02 PM, Ralph Boehme <rb at sernet.de> wrote:
> On Fri, Oct 16, 2015 at 04:55:45PM -0700, Jeremy Allison wrote:
>> On Fri, Oct 16, 2015 at 11:04:57PM +0200, Ralph Boehme wrote:
>> > On Fri, Oct 16, 2015 at 01:22:51PM -0700, Richard Sharpe wrote:
>> > > Hi folks,
>> > >
>> > > I am having problems reconciling this man connect with respect to EINPROGRESS:
>> > >
>> > >               The  socket  is  non-blocking  and the connection cannot be com-
>> > >               pleted immediately.  It is possible to select(2) or poll(2)  for
>> > >               completion by selecting the socket for writing.  After select(2)
>> > >               indicates writability, use getsockopt(2) to  read  the  SO_ERROR
>> > >               option  at  level SOL_SOCKET to determine whether connect() com-
>> > >               pleted  successfully  (SO_ERROR  is  zero)   or   unsuccessfully
>> > >               (SO_ERROR  is one of the usual error codes listed here, explain-
>> > >               ing the reason for the failure).
>> > >
>> > > However, the code in async_connect_connected simply calls connect
>> > > again, which strace tells me is getting ECONNREFUSED ...
>> > >
>> > > So, I am confused ...
>> > >
>> > > Perhaps there is some missing code for the AF_INET case?
>> >
>> > at first glance, the code in async_connect_connected seems wrong to
>> > me. The right thing to do would be calling getsockopt() as described
>> > in the manpage.
>> >
>> > Calling connect() a second time on a non-blocking socket with a
>> > previous connect in flight would return EALREADY according to man
>> > socket(2).
>>
>> Or EISCONN (according to connect(2)).
>>
>> The getsockopt() fix seems best. Do you want to code it
>> up or shall I ?
>
> will do it.
>
> -Ralph

I have a suspicion that SeLinux is causing my problem ... so hold off on that.

I coded up a fix that should work but causes the same problem, and a
perusal of the kernel sources yesterday suggested SeLinux as the
culprit :-)

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)