Hurrey
I have the solution!
:clap::-D
If SSL_get_error give SSL_ERROR_NONE
I test with strcmp ( at the end, "") .
because all data from the server must end with "".
If my data is not complete I send CR LF and the last 975 Bytes appeared
SSL_write(mySSL->ssl,"\r\n", 2);
Thanks Peter
-
On Thu, Jul 31, 2008 at 05:14:09PM -0700, David Schwartz wrote:
>
> Let me just state this one more time one other way to help people wrap their
> brain around it. The OpenSSL library is a black box. You are not supposed to
> look inside the black box.
>
> If you want to get decrypted plaintext f
Let me just state this one more time one other way to help people wrap their
brain around it. The OpenSSL library is a black box. You are not supposed to
look inside the black box.
If you want to get decrypted plaintext from the black box, the black box may
or may not need to read data from the s
> > If this is really what's happening, it's a bug in OpenSSL. The
> > application
> > should be able to pass a 1-byte buffer the OpenSSL and get 1 byte of
> > decrypted data.
> Consider that when running with the current non-blocking API, once OpenSSL
> takes the data out of the socket buffer, b
On Thu, Jul 31, 2008 at 01:02:16PM -0700, David Schwartz wrote:
>
> > Let me trace through the application. Looking at the source code, it
> > appears that the application may have a bug (checking the SSL error stack
> > via SSL_get_error() when SSL_read() returned > 0) but that what
> > is actua
> Let me trace through the application. Looking at the source code, it
> appears that the application may have a bug (checking the SSL error stack
> via SSL_get_error() when SSL_read() returned > 0) but that what
> is actually
> happening here is:
>
> 1) SSL_read() is returning < 0, SSL_get_error
On Thu, Jul 31, 2008 at 11:49:05AM -0700, David Schwartz wrote:
>
> > 3) We call SSL_read with our 8k buffer. The received data does not fit,
> >so OpenSSL buffers it internally and returns 8K with
> > SSL_ERROR_WANT_READ.
>
> How it can both succeed (returning 8K) and fail (returning
> SSL_
> 3) We call SSL_read with our 8k buffer. The received data does not fit,
>so OpenSSL buffers it internally and returns 8K with
> SSL_ERROR_WANT_READ.
How it can both succeed (returning 8K) and fail (returning
SSL_ERROR_WANT_READ)?
DS
__
I think I've discovered another problem with the current non-blocking API.
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To conserve memory I reduced the buffer
