I should have put this in...
The problem is the socket should be blocking, but for some reason, it has
become non-blocking. Using Observer and stepping through the code, I
verified
that the client sends the client hello message and the server responds with
the server hello message. The format and certificates of these messages are
correct. For some reason, recv never gets the data from the server. All the
client gets is a -1 and is forced to give up without the option of trying
to receive data again. I tried a loop within openSSL to retry reading the
data if a WSAEWOULDBLOCK error is generated. This works for one or two reads
(only reading a few bytes of a couple of hundred); however, an access
violation occurs later deep within openSSL.
OpenSSL was working fine with our application (it still works fine on Unix).
We have already eliminated all of our known memory leaks.
Paul Kudlawiec
Software Engineer
Transnexus
[EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bodo Moeller
> Sent: Monday, October 23, 2000 12:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Receiving WSAEWOULDBLOCK on Windows NT only
>
>
> On Mon, Oct 23, 2000 at 10:40:56AM -0400, Paul Kudlawiec wrote:
>
> [...]
> > While using SSL_write, it returns a -1 for the number of
> bytes written. I
> > tracked down the line generating the error; it occurs during the
> > get_server_hello process:
> > ret=readsocket(b->num,out,outl);
> > (located in bss_sock.c: line 190)
> > "readsocket" is actually a macro for "recv". A
> WSAEWOULDBLOCK error is
> > generated here meaning that the receive operation would
> block even though
> > the socket is marked as nonblocking.
>
> What's the problem here? SSL_write has to read data (a
> handshake is going on)
> but none is available, so WSAEWOULDBLOCK occurs.
> "...WOULDBLOCK" conditions
> occur *only* with non-blocking sockets; blocking sockets
> simply block instead.
>
>
> [...]
> > I used Purify to see if there are any memory leaks etc. I
> don't know if this
> > is the cause, but there were a number of warnings generated
> before it
> > reached
> > this line, occurring mostly around the following sections of code:
> >
> > Uninitialized Memory Reads:
> > SHA1Update [sha1dgst.c:167]
> > SHA1Update [sha1dgst.c:168]
> > SHA1Update [sha1dgst.c:171]
> > SHA1Update [sha1dgst.c:140]
> > SHA1Final [sha1dgst.c:461]
>
> This appears to be the PRNG, which has no reason not to read
> from uninitialized
> memory.
>
>
>
> --
> Bodo M�ller <[EMAIL PROTECTED]>
> PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
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]
