[copied to private email as well as the list]
Thank-you very much! That's exactly what I needed. I must also apologise on
two accounts:
1: I thought I had based my code on s_client, and can't see now how I ended
up so confused.
2: I have already replied to another email of yours asking about select and
have no idea how to stop it from going out when I dial-up (I have just
started using email via the telephone, having moved away from the office, and
am still learning how to live with a slow, expensive, and intermittent link
to the internet...) - the answer to my question is that select is necessary
(for emulating blocking read) because there is insufficient data, but it is
possible for select to indicate data and SSL to still return -1 with
WANT_READ, in which case I need to select again (until a full block has been
read into the SSL buffer).
Cheers,
Andrew
Bodo Moeller wrote:
> 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]
