[[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.


> 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,

OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to