[openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

Following works :

If(BIO_should_read(socket->ssl_bio) != 0)

If(BIO_should_write(socket->ssl_bio) != 0)

With this, I could get the entire end-to-end workflow to work !!!!

Thanks a ton for all the help !!!

On Mon, Oct 10, 2016 at 11:50 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> Hi All.
>
> Taking the socket-structure as ::
>
> ############################################################
> #####################################
>            SSL *ssl;
>
>            BIO *ssl_bio;                 // app-payload-bytes will be
> written by app into it.
>            BIO *inter_bio;               // intermediate-bio, have no idea
> what it really is used for.
>            BIO *network_bio;          // app-payload-encrypted-bytes will
> "emerge" from this bio, ready to be written over the wire
> ############################################################
> #####################################
>
>
>
>
> and assuming all initialization went fine, what is the correct way to get
> the retry-reason ::
>
> ############################################################
> #####################################
>         if(BIO_should_retry(socket->ssl_bio) != 0)
>         {
>               int reason =  BIO_get_retry_reason(socket->ssl_bio);
>         }
>
>                                               OR
>
>         if(BIO_should_retry(socket->ssl_bio) != 0)
>         {
>               int reason = BIO_get_retry_reason(BIO_get_retry_BIO(socket->ssl_bio,
> NULL));
>         }
> ############################################################
> #####################################
>
>
> Right now, I am receiving 0 (zero) as the reason in both the cases, and
> none of SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ (in either case).
>
>
> Thanks and Regards,
> Ajay
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/fff9d985/attachment-0001.html>