OK, I followed the advice documented for the SSL_ERROR_SYSCALL case and
since ERR_get_error() returns 0, ended up with this situation :
"If *ret == 0*, an EOF was observed that violates the protocol."
Disabling the server results in SSL_connect never returning, so I
suspect that, when the server is enabled, it hangs up on the client
before the handshake is complete. Why would it do that? Can the clients'
ssl give me anymore information?
On 19/02/13 11:49, Dr. Stephen Henson wrote:
On Tue, Feb 19, 2013, T J wrote:
I think it might be my client as SSL_connect() is returning 0. When
I plug that value + the clients' ssl into SSL_get_error(), it
returns a value of 5. strerror(5) returns "Input/output error". Not
much help there! Can anyone point me in the right direction to track
that down further to find exactly what I/O problem is occurring?
As has been mentioned the return value from SSL_get_error wont produce any
meaningful results when passed to strerror.
The return value of SSL_get_error (as stated in the manual page) should be
interpreted as one of the SSL_ERROR_* codes. In this case '5' corresponds to
SSL_ERROR_SYSCALL which means the underlying transport returned an error code
when OpenSSL tried to use it which doesn't correspond to an I/O operation that
should be retried.
As mentioned in that manual page examining the error queue and/or errno should
give you more details.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
