SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN

[John Unsworth]

Just a thought. Would it not be possible for the SSL session to create a mutex and lock it where required?
Error details could be stored in Thread Local Storage to obliviate the need to call SSL_get_error() within the mutex block.

Regards,
John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of John Unsworth
Sent: 07 May 2019 09:06
To: openssl-users at openssl.org
Subject: RE: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN

CAUTION: This email originated from outside of Synchronoss.


Thanks, the mutex is tied to the SSL session and used for all calls (now!).

The good news is that moving SSL_get_error() into the same mutex unit as SSL_read() has solved the problem.

Thank you for all your help and advice.

Regards,
John.

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Viktor Dukhovni
Sent: 03 May 2019 23:04
To: openssl-users at openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN

CAUTION: This email originated from outside of Synchronoss.


On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote:

> Testing changed code.

For the record, though I think you realise this, *both* the SSL_read()
or SSL_write() and the following SSL_get_error() need to be protected
as a unit by the *same* instance of the locked mutex.  It would not
be enough to lock these separately.

    acquire_lock();
        if (reading)
            ret = SSL_read(ssl, ...);
        else
            ret = SSL_write(ssl, ...);
        if (ret <= 0)
            err = SSL_get_error(ssl, ret);
    release_lock();

    /* Handle EOF and errors */

--
        Viktor.