This is what we do: Create a non-blocking TCP socket. Call SSL_new(), SSL_set_fd(), SSL_connect() Thereafter call SSL_read(). Renegotiates handled by OpenSSL. We have only seen the error very occasionally, the vast majority of calls return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The following is traced when we get the fail, originally we then caused a disconnect but now handle it as discussed: LDAP: session=7F38AE82F840 socket read error SSL Error Syscall: LastError 11 Note that because our code automatically reconnects and reissues failed and aborted operations customers would not normally see the error. In this case though we disconnected while a modify operation was running in the LDAP server, after reconnecting the modify was reissued and failed because of attribute deletion by the original modify. The investigation showed up the error. The customer was running a soak test and thousands (maybe millions) of reads worked fine until the failing one. Regards, John. -----Original Message----- From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Erik Forsberg Sent: 01 May 2019 03:05 To: openssl-users@xxxxxxxxxxx Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN CAUTION: This email originated from outside of Synchronoss. >-- Original Message -- > > >>-- Original Message -- >> >>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: >> >>> >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. >> >>Recoverable errors should not result in SSL_ERROR_SYSCALL. This feels >>like a bug. I'd like to hear from Matt Caswell on this one. >>Perhaps someone should open an issue on Github... >> >I will scan my logs later this evening and see if this is still an issue. >Last time I remember seeing it was quote some long time ago (couple of >years) > > ok, I checked my logs (3+ years worth of them) and I have not seen this error in that timeframe. so it must have been a much older OpenSSL version I used way back when I remember doing this workaround. Doesnt seem to be needed for me anymore.
