SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN

[Erik Forsberg]

I can add some of my own observations to this below ...

>> I haven't looked at the code, but my impression is that WANT_READ and WANT_WRITE are returned in two cases: when OpenSSL has received or sent a partial record and needs to complete it; or when the TLS state is such that OpenSSL needs to perform the associated operation and it hasn't been requested by the application - for example, if the application is trying to receive data but OpenSSL needs to send renegotiation information.
>> 
>> If you do a non-blocking receive at a record boundary (so you don't have an incomplete record) and OpenSSL doesn't currently need to send for TLS reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on platform). I think in this case it does just return SSL_ERROR_SYSCALL, because OpenSSL itself doesn't "want" to receive. If OpenSSL had already received a partial record, then you'd get WANT_READ.
>
>I think the above guess is not correct.  A cursory look at the
>code suggests that even user-initiated reads normally return
>SSL_ERROR_WANT_READ when the network bio signals a retriable
>failure.
>
>The OP has not provided much detail about the connections in
>question are created.  Is the connection made by the
>application, and SSL negotiated over an existing socket, or
>is the connection established by OpenSSL over a "connect bio"?
>
>Is the handshake explicit, or does the application just call
>SSL_read(), with OpenSSL performing the handshake as needed?
>

I occasionally (somewhat rarely) see the issue mentioned by the OP.
Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE
does effectively hides the issue and connection works fine. I predominantly
run on Solaris 11. In my case, I open the socket myself, set non-blocking
mode and associates with an SSL object using SS_set_fd().
The initial handshake is done explicitly.