Hi,

Our application sends/receives audio/video streams on a ssl connection. The
i/o is done by our application and we communicate with the ssl library via
BIO_read/BIO_write and SSL_write/SSL_read. All operations are non blocking.
Everything works fine until the processed packets per second exceeds some
limit. Then we get immediatly decoding errors in the ssl library (The
transmitted MAC is different from the calculated one). 

While debugging we found the following problem:

If we receive some data we process it via one BIO_write call followed by
SSL_read calls until the call to SSL_read fails with SSL_get_error() ==
SSL_ERROR_WANT_READ or SSL_read returns no more data (SSL_ERROR_WANT_WRITE
is also handled correctly - I hope). Then we stop reading from the ssl
connection until we receive new data. We assume, we can now safely send
data in the opposite direction using SSL_write/BIO_read. It seems that this
assumption is wrong because: sometimes there seems to be state information
(SSL->s2->three_byte_header?) in the ssl connection which is needed by
following calls to BIO_write/SSL_read. It looks like this state information
is overwritten by the SSL_write/BIO_read calls and therefore a following
BIO_write/SSL_read will fail. We have found a workaround for this problem -
our send routine now looks like:

int SendSomeDataOverSSL(SSL* ssl, void* data, int length);
{
        if (ssl->rstate != SSL_ST_READ_HEADER) {
            // HACK: preserve internal state of the ssl connection 
            // we will discard this packet, the upper layer will handle the
loss correctly
            return 0;
        }

        bytesWritten = SSL_write(ssl, data, length);
        assert(bytesWritten == length);
       char sendbuffer[bufferlen]
        wile ((length = BIO_read(con.bioWrite, sendbuffer, bufferlen)) > 0) {
                res = send(socket, sendbuffer, length);
        }

       return 1;
}


This works but it is only a hack, of course (and may deadlock sometimes if
ssl->rstate == SSL_ST_READ_HEADER on both sides of the connection at the
same time). What we are doing wrong?

(We are using OpenSSL version 0.9.7g.)


Best regards,
Henrik Thürmer


----------------------------------------------
VidSoft GmbH      | phone: +49 351 43534 05
Lortzingstraße 35 | fax:   +49 351 43534 28
D-01307 Dresden   | www:   www.vidsoft.de
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to