> On Apr 30, 2019, at 12:31 PM, Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> wrote:
>
> I haven't seen a reply to this, so I'll take a stab...
>
> 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?
In any case, I would not expect SSL_ERROR_SYSCALL under normal
conditions. The documentation says:
SSL_ERROR_SYSCALL
Some non-recoverable, fatal I/O error occurred. The OpenSSL error
queue may contain more information on the error. For socket I/O on
Unix systems, consult errno for details. If this error occurs then
no further I/O operations should be performed on the connection and
SSL_shutdown() must not be called.
This value can also be returned for other errors, check the error
queue for details.
--
Viktor.
