[EMAIL PROTECTED] wrote:
Once again bodo shows the way. The point is that when you are taking time to
comment at length about a function you should copy BM's format and write up the
documentation yourself and submit it to the list. This will be reviewed by the
relevant parties and after awhile we can start collecting this and distributing
it with the code.
Brad
> The questions Amnon asked were where to find man pages. This man page is
> an excellent example of the type of documentation people are looking for.
>
> To ask the questions in a slightly different manner. Where does one look
> to find Openssl documentation in a form similar to that provided for
> SSL_get_error?
>
> Jim
>
> "Pablo J. Royo" <[EMAIL PROTECTED]> on 01-27-2000 03:33:41 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To: [EMAIL PROTECTED]
> cc: (bcc: James Gonzalez/IT/NMPC)
>
> Subject: Re: SSL_connect() fails on non-blocking sockets.
>
> I think the best way is to look up in the apps directory s_client and
> s_server examples.You will see that SSL_connect() is in a loop, and also
> SSL_accept() in the server part (as far as I remember) .Then, you can also
> see a SSL_should_retry() function that encapsulates all this kind of errors.
>
> >Hi!
> >
> >Where did you get the man page for SSL_get_error() from?
> >How can I find man pages for other SLL functions?
> >
> >Thanks
> > Amnon Cohen
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]]
> >> Sent: Wednesday, January 26, 2000 12:35 AM
> >> To: [EMAIL PROTECTED]
> >> Cc: Matti Aarnio
> >> Subject: Re: SSL_connect() fails on non-blocking sockets.
> >>
> >>
> >> Matti Aarnio <[EMAIL PROTECTED]>:
> >>
> >> > It turned out that while the socket the SMTP client code creates is
> >> > running in non-blocking mode, I must temporarily turn the
> >> blocking mode
> >> > on while the SSL setup negotiations are under way.
> >> > I don't know if creating some wrapper to retry calls to
> >> SSL_connect()
> >> > would have helped, but such would have been rather massively kludgy
> >> > thing..
> >>
> >> SSL_connect needs multiple I/O operations in both directions,
> >> so you cannot expect it to finish at once for non-blocking I/O.
> >> SSL_connect returning -1 does not always indicate an error.
> >> Use SSL_get_error to find out if the application should
> >> select() for readable bytes or for a possibility to write
> >> more data.
> >>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >>
> >> NAME
> >> SSL_get_error - obtain result code for SSL I/O operation
> >>
> >> SYNOPSIS
> >> #include <openssl/ssl.h>
> >>
> >> int SSL_get_error(SSL *ssl, int ret);
> >>
> >> DESCRIPTION
> >> SSL_get_error() returns a result code (suitable for the C
> >> "switch" statement) for a preceding call to SSL_connect(),
> >> SSL_accept(), SSL_read(), or SSL_write() on ssl. The value
> >> returned by that SSL I/O function must be passed to
> >> SSL_get_error() in parameter ret.
> >>
> >> In addition to ssl and ret, SSL_get_error() inspects the current
> >> thread's OpenSSL error queue. Thus, SSL_get_error() must be used
> >> in the same thread that performed the SSL I/O operation, and no
> >> other OpenSSL function calls should appear inbetween. The
> >> current thread's error queue must be empty before the SSL I/O
> >> operation is attempted, or SSL_get_error() will not work
> >> reliably.
> >>
> >> RETURN VALUES
> >> The following return values can currently occur:
> >>
> >> SSL_ERROR_NONE
> >> The SSL I/O operation completed. This result code is
> >> returned if and only if ret 0>.
> >>
> >> SSL_ERROR_ZERO_RETURN
> >> The SSL connection has been closed. If the protocol version
> >> is SSL 3.0 or TLS 1.0, this result code is returned only if
> >> a closure alerts has occured in the protocol, i.e. if the
> >> connection has been closed cleanly.
> >>
> >> SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
> >> The operation did not complete; the same SSL I/O function
> >> should be called again later. There will be protocol
> >> progress if, by then, the underlying BIO has data available
> >> for reading (if the result code is SSL_ERROR_WANT_READ) or
> >> allows writing data (SSL_ERROR_WANT_WRITE). For socket BIOs
> >> (e.g. when SSL_set_fd() was used) this means that select()
> >> or poll() on the underlying socket can be used to find out
> >> when the SSL I/O function should be retried.
> >>
> >> Caveat: Any SSL I/O function can lead to either of
> >> SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE, i.e.
> >> SSL_read() may want to write data and SSL_write() may want
> >> to read data.
> >>
> >> SSL_ERROR_WANT_X509_LOOKUP
> >> The operation did not complete because an application
> >> callback set by SSL_CTX_set_client_cert_cb() has asked to be
> >> called again. The SSL I/O function should be called again
> >> later. Details depend on the application.
> >>
> >> SSL_ERROR_SYSCALL
> >> Some I/O error occurred. The OpenSSL error queue may contain
> >> more information on the error. If the error queue is empty
> >> (i.e. ERR_get_error() returns 0), ret can be used to find
> >> out more about the error: If ret == 0, an EOF was observed
> >> that violates the protocol. If ret == -1, the underlying BIO
> >> reported an I/O error. (For socket I/O on Unix systems,
> >> consult errno.)
> >>
> >> SSL_ERROR_SSL
> >> A failure in the SSL library occured, usually a protocol
> >> error. The OpenSSL error queue contains more information on
> >> the error.
> >>
> >> SEE ALSO
> >> ssl(3), err(3)
> >>
> >> HISTORY
> >> SSL_get_error() was added in SSLeay 0.8.
> >>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
