[This is a guess]
It appears that the SSL decryption engine does not have enough data to
proceed. Have you verified that the sender really has sent the entire
message. 300 bytes sounds about right for a packetized, encrypted
message. If you are using a custom-written client, try forcing a flush(
) on the stream. If this is not a custom build, you may have a problem
with your select( ) call (I am not familiar with MS-style unix calls).
HTH
-Sean Walton
Quickling wrote:
> Hi,
>
> (this is an updated question, re-posted because I'm stuck and
> scared.)
>
> I've implemented a dual thread socket event pump that uses
> OpenSSL for security - I'm doing all socket management.
> I get a connection request, I accept the socket. Then I
> call SSL_accept() on the socket and note whether WANT_READ
> or WANT_WRITE. Next time I get an event on the socket, I
> I call SSL_accept(), ad finitum. The problem, which happens
> only occassionally, and only when the host system is under
> stress, is that this process may fail because (it appears)
> SSL stops reading from the socket, despite the fact that
> SSL_accept() told me WANT_READ and ioctl with FIONREAD
> tells me there are 51 bytes sitting to be read! This sends
> my select() thread into overdrive because the untouched
> data triggers select() immediately (and continuously).
> Ouch.
>
> My question is: why isn't SSL guaranteed to read from the
> socket if there are bytes available? If I have no way of
> knowing whether or not it took the data (other than the
> dubious ioctl/FIONREAD call) how can I know whether I
> should add it back into my select fd_set? Especially
> since there seems to be times that this behaviour (leaving
> data on the socket) is normal for OpenSSL - if I get
> an 8K chunk on the socket, SSL_read() will extract the
> smaller ~300 byte packets one at a time but ioctl reports
> that SSL does not take any bytes off the socket until the
> entire 8K have been decrypted, some N SSL_reads down the
> road - I'm confused how it does this. Or perhaps my
> system's ioctl/FIONREAD doesn't work properly? Yet the
> results (select() returning instantly on that socket)
> indicate this is actually what's happening.
>
> Further odd behaviour is that SSL may _eventually_ take
> the data, perhaps after spinning 400 times on it - what's
> the deal? Is it because the coveted 52nd byte came in?
>
> Finally, there is a case where SSL_accept() returns success,
> but directly thereafter there are 51 bytes waiting on the
> socket that SSL_read() now refuses to take! Argh! You
> can imagine the results.
>
> I'm using version 0.9.6 with win32/MSVC++. I compiled the
> openssl DLLs with dynamic linkage to the multithreaded
> runtime libraries just as I do in my main project, so there
> should be no evil library mixing problems. I use one
> sslContext for all connections, and one sslSession per
> socket of course. BTW, my socket code, operating in
> insecure mode (without SSL) works quite well; I can run
> 2000 actively talking sockets between a client and a
> server with no breakdown. I *can* run 1000 secure sockets,
> but only if I connect them slowly enough to avoid the
> wicked non-read problem, which only seems to happen
> detrimentally during SSL setup.
>
> I'm a newbie at this SSL - I've got it almost running but
> this stuff will kill me if I don't fix it - any help is
> appreciated. Sorry for the verbosity of the post -
> congrats if you made it this far ;\
>
>
> Thanks,
> Quick
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
