[[EMAIL PROTECTED] - Sun Nov 24 19:52:37 2002]:
> Hi!
>
> I have a small problem with SSL_get_error. This function starts like
> this:
>
> int SSL_get_error(SSL *s,int i)
> {
> int reason;
> unsigned long l;
> BIO *bio;
>
> if (i > 0) return(SSL_ERROR_NONE);
>
> /* Make things return SSL_ERROR_SYSCALL when doing
> SSL_do_handshake
> * etc, where we do encode the error */
> if ((l=ERR_peek_error()) != 0)
> {
> if (ERR_GET_LIB(l) == ERR_LIB_SYS)
> return(SSL_ERROR_SYSCALL);
> else
> return(SSL_ERROR_SSL);
> }
>
> Now, if I have something in the error stack from previous operations
> and I
> call SSL_read or SSL_write on non-blocking socket and read or write
> returns -1 and sets errno to EAGAIN, then SSL_get_error will return
> SSL_ERROR_SSL which makes this error look like an error in SSL
> statemachine but it is really not.
>
> Since BIO_f_ssl does not set retry flag for SSL_ERROR_SSL connection
> aborts.
Ooops.
> One solution to this problem is to make sure that ERR_clear_errors
> gets
> called every time before you do SSL_read or SSL_write (or
> BIO_read/BIO_write). But I think that this is not a very good
> approach,
> because it relies on the good habbits of the application programmer.
> Calling ERR_clear_errors automatically at the start of SSL_read and
> SSL_write might hurt the performance and is therefore probably not a
> very
> good solution.
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors() combined with clear_sys_error()
but obviously not in all occasions.
Unfortunately it is not obvious enough to simply add it without some
further investigation. I will thus put this issue into the 0.9.7 queue
and will not consider it for 0.9.6h anymore.
> I suggest that if the exact kind of the error is important we should
> add
> an explicit parameter to the lower level functions to return this
> information. Or additional status fields to strucutres like SSL.
Even though this seems to be a reasonable proposal, I am afraid that it
would require significant changes to the error handling concept...
Best regards,
Lutz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
