Thor Lancelot Simon wrote: > 1) I have data to write, and the SSL session's descriptor > selects as ready-to-write.
This already scares me. You have data to write on the unencrypted stream to the SSL connection. The SSL session's descriptor write is for the encrypted stream between SSL implementations. Why would you check one when you want to write to the other? You should only be calling 'select' to see if a descriptor is ready-to-write if you know you need to write on that descriptor. Since SSL_write did not return 'WANT_WRITE', you had no way to know OpenSSL needed to write on the socket. > 2) I call SSL_renegotiate. I do understand that in a server > application this merely sends the client a request to > do a new handshake, which the client can ignore. > > 3) I generate more data and several more SSL_writes() complete > normally. > > 4) Eventualy the SSL session's file descriptor selects as > ready-to-read. Did an SSL_read return WANT_READ? If not, why were you selecting on the file descriptor for read? What you are doing makes failure scenarios possible. Consider: 1) You call SSL_write. Since a renegotiation is in progress, it tries to read the data to complete the rengotiation. 2) It reads the renegotiation data, and some application data. It completes the write. 3) You select on the socket for 'read', but you don't get a hit because the data has already been read. So why were you waiting for the SSL session's file descriptor to select as ready-to-read? An SSL connection has *ONE* *STATE*. When SSL_write completes normally, its state is "everything is fine". It's state is *NOT* "want read", which seems to be what you were assuming. > 5) I call SSL_read with a 4096-byte buffer. SSL_read returns > -1 and error is SSL_ERROR_WANT_READ. So now you know that a read hit from select is needed (or other forward progress must be made) before SSL_read can succeed. > 6) I set a flag to ensure I do not call SSL_write() (it isn't > clear to me this is necessary -- the documentation is vague) > and select on the SSL session's descriptor for read. Why would you avoid writing? It's possible the other side will not send any application data. > 7) The SSL session's file descriptor selects as ready for read, > I call SSL with the same 4096 byte buffer at the same address, > and SSL_read returns -1 and error is SSL_ERROR_SSL. > > I cannot understand why #7 occurs. Is SSL_MODE_ENABLE_PARTIAL_WRITE just > incompatible with non-blocking mode and renegotiations? Perhaps the other side gave up waiting for you and closed the connection down abruptly? What does the other side show when this happens? DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org