Hello,
> > > If anyone thinks that 'select' or 'poll' guarantees that a future
> > > operation
> > > will not block, even if it's a single operation, that's just plain not
> > > true.
> > > The only way you can guarantee that even one operation will not block is
> > > if
> > > you set the socket non-blocking.
> >
> > Really.
> >
> > I dont think the IEEE and POSIX specifications are publicly available to
> > quote you an extract. However the Linux man page talks in those
> > specific terms of a descriptor becoming writingable means that a write
> > operation will not block (I think its widely accepted that they are
> > referring to only the next single invocation of write() will not block).
>
> Linux:
> Three independent sets of descriptors are watched. Those listed in
> readfds will be watched to see if characters become available for read-
> ing (more precisely, to see if a read will not block - in particular, a
> file descriptor is also ready on end-of-file)
>
> R. Stevens, Unix Network Programming, Volume 1, Second Edition, Section
> 6.3, page 153:
>
> 1. A socket is ready for reading if any of the following four conditions
> is true:
>
> a. The number of bytes of data in the socket receive buffer is greater
> than or equal to the current size of the low-water mark for the socket
> receive buffer. *** A read operation on the socket will not block and will
> return a value greater than 0 (i.e., the data that is ready to be read).***
> We can set this low-water mark using the SO_RCVLOWAT socket option. It
> defaults to 1 for TCP and UDP sockets.
>
> b. The read half of the connection is closed (i.e., a TCP connection that
> has received a FIN). A read operation on the socket will not block and
> will return 0 (i.e., EOF).
>
> c. The socket is a listening socket and the number of completed
> connections is nonzero.
> An accept on the listening socket will normally not block, although we
> will describe a timing condition in Section 16.6 under which the accept
> can block.
>
> d. A socket error is pending. A read operation on the socket will not
> block and will return an error (.1) with errno set to the specific error
> condition. These pending errors can also be fetched and cleared by calling
> getsockopt and specifying the SO_ERROR socket
> option.
Sorry for late response but I was out of office.
In s_client we have TCP blocking socket and SSL stack on it
working with SSL_MODE_AUTO_RETRY mode off.
In this mode (according to OpenSSL documentation) we may received
SSL_ERROR_WANT_READ if renegotiation occurs.
>From OpenSSL SSL_read() documentation:
-- If the underlying BIO is blocking, SSL_read() will only return,
-- once the read operation has been finished or an error occurred,
-- except when a renegotiation take place, in which case a
-- SSL_ERROR_WANT_READ may occur.
So application should be prepared for this event -
because this may happen. If application will not support this
situation, when SSL renegotiation occurs, application may simply
drop connection thinking that some critical error occured.
In discussed case we have started renegotiation (handshake packets
exchange) and ONE PACKET with application data IN RENEGOTIATION.
First SSL_read() after select():
- read hello_request (handshake - renegotiation)
- write client_hello (handshake - renegotiation)
- read UNEXPECTED ENCRYPTED APPLICATION DATA
this data may be returned to caller because OpenSSL has
support for such case.
Second SSL_read() after select():
- read/write rest of renegotiation packets
- read for application data <-- and here we have HANG
I made assumption:
- s_client wants to work in this SSL mode
- s_client is prepared for SSL_ERROR_WANT_READ event
(because it is :-)
so solution for this may be return from SSL_read() with
SSL_ERROR_WANT_READ when full/partial renegotiation is performed.
Of course, we may discuss when we should do this, after reading
one handshake packet, or after all renegotiation, or in other way,
but past discussion develop in wrong way:
- you're screwed
- no, you're screwed
- no, no, you're screwed
- no, no, no, you're screwed
But I'm talking about facts and real implementation - not theory.
Best regards,
--
Marek Marcola <[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
