On Tue, Apr 13, 1999 at 12:00:00AM +0000, Andrew Cooke wrote:
> I am reading across the network, using SSLeay-0.9.0.b, and have an
> intermittent problem - the sending socket is being closed, but this is
> not always being detected by the receiving SSL. In particular,
>
> SSL_read(ssl, buffer, length)
>
> is returning zero rather than -1.
The return value zero means that the connection has been closed (well,
unless you called read() with length == 0, which does not make too
much sense). Look at s_client.c: First there's the call
k = SSL_read(con, ...),
and then there's
switch (SSL_get_error(con, k)).
The definition of SSL_get_error is in ssl/ssl_lib.c: SSL_ERROR_NONE
is returned if k > 0. If k == -1, either an error code is chosen, or
SSL_ERROR_WANT_WRITE / SSL_ERROR_WANT_READ is returned (there are a
few more special cases that I'll omit here). These
SSL_ERROR_WANT_... return values are only used for non-blocking I/O.
They tell the calling program that it should wait until the socket is
writable or readable, respectively, and then call the library function
again. If k == 0, either SSL_ERROR_ZERO_RETURN or SSL_ERROR_SYSCALL
will be returned. If it's SSL_ERROR_ZERO_RETURN, s_client closes its
connections immediately.
> This seems to be a bug, possibly connected with non-blocking reads. So
> is there a fix and/or can anyone describe how to do blocking reads
> [...]
Look at s_client.c and s_server.c. A return value of 0 has nothing to
do with non-blocking I/O: For non-blocking sockets, the return value
of un unsuccesful SSL_read() is -1 (as it is for OS level sockets),
and the error code tells the application that it should wait until the
I/O operation can take place (the program should use select() or
poll() for this). Different from standard read() which returns EAGAIN
aka EWOULDBLOCK if there's no data available for non-blocking I/O [1],
SSL_read() has two different possibilities: The system call that could
not be completed may either have been a read()/recv() or -- if a
handhsake is taking place -- a write()/send(). This is indicated by
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, respectively.
[1] This is POSIX O_NONBLOCK semantics. There's also the old System V
O_NDELAY semantics where read() might return 0 and you cannot
tell if this means EOF or that you should just wait. That's
broken by design.
> PS. Further info:
> BIO_eof(SSL_get_rbio(ssl)) is also returning zero
For sockets, BIO_eof is just a dummy function.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
