Deadlock - SSL_Connect()

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Deadlock - SSL_Connect()

Nathan Smyth
Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code.

The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant?

I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated.

Thanks!
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deadlock - SSL_Connect()

Gayathri Sundar-3
did you try making use of non blocking fd? it cannot deadlock in if you use that.

Thanks
--Gayathri

On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth <[hidden email]> wrote:
Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code.

The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant?

I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated.

Thanks!
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deadlock - SSL_Connect()

Nathan Smyth
Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work...

Could there be some issue with numerous SSL connections between the same parties? Or maybe it's some threading issue - perhaps SSL has some special considerations?


From: Gayathri Sundar <[hidden email]>
To: [hidden email]
Sent: Monday, 16 January 2012, 16:21
Subject: Re: Deadlock - SSL_Connect()

did you try making use of non blocking fd? it cannot deadlock in if you use that.

Thanks
--Gayathri

On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth <[hidden email]> wrote:
Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code.

The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant?

I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated.

Thanks!
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Deadlock - SSL_Connect()

Gayathri Sundar-3
you should be setting the non blocking thing before the ssl connect is called, which is part of the SSL handshake. SSL_connect will internally do socket read/write, so if its blocking then it will not come out until the underlying operation is completed. setting it after the SSL connect is done, will help only on application data read/write.

Thanks
--Gayathri

On Mon, Jan 16, 2012 at 10:47 AM, Nathan Smyth <[hidden email]> wrote:
Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work...

Could there be some issue with numerous SSL connections between the same parties? Or maybe it's some threading issue - perhaps SSL has some special considerations?


From: Gayathri Sundar <[hidden email]>
To: [hidden email]
Sent: Monday, 16 January 2012, 16:21
Subject: Re: Deadlock - SSL_Connect()

did you try making use of non blocking fd? it cannot deadlock in if you use that.

Thanks
--Gayathri

On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth <[hidden email]> wrote:
Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code.

The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant?

I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated.

Thanks!
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: Deadlock - SSL_Connect()

Michael S. Zick-4
In reply to this post by Nathan Smyth
On Mon January 16 2012, Nathan Smyth wrote:
> Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work...
>
> Could there be some issue with numerous SSL connections between the same parties? Or maybe it's
> some threading issue - perhaps SSL has some special considerations?
>

Like in defining the locking call backs maybe?
See the OpenSSL docs for details.

Mike

>
> ________________________________
>  From: Gayathri Sundar <[hidden email]>
> To: [hidden email]
> Sent: Monday, 16 January 2012, 16:21
> Subject: Re: Deadlock - SSL_Connect()
>  
>
> did you try making use of non blocking fd? it cannot deadlock in if you use that.
>
> Thanks
> --Gayathri
>
>
> On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth <[hidden email]> wrote:
>
> Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code.
> >
> >The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant?
> >
> >I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated.
> >
> >Thanks!
> >______________________________________________________________________
> >OpenSSL Project                                 http://www.openssl.org
> >User Support Mailing List                    [hidden email]
> >Automated List Manager                           [hidden email]
> >


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]