Re: [openssl.org #514] Bug in OpenSSL????

2003-03-06 Thread Ralph via RT



Bodo Moeller via RT wrote:

Ralph via RT [EMAIL PROTECTED]:

  

But so far, I can tell you that when SSL_get_error() returns 
SSL_ERROR_SYSCALL and you inspect errno, it tells EWOULDBLOCK or EAGAIN. 
By  repeating the SSL_* call as long as this condition occurs, I can 
overcome the problem and the SSL handshake and communication works 
perfectly. Oh...it's in a multi-threaded application, too! Maybe this 
helps (OpenSSL compiled with the correct switch for MT - I hope)



If OpenSSL is *not* compiler with correct switches for multithreading,
that would explain -- in that case, SSL_get_error() could be reading
the wrong copy of errno and thus not find the EWOULDBLOCK/EAGAIN code.

Here's something to try: find the 'errno' definition for multi-threading
in the system header files, which should involve some function call;
then use 'nm' to see if that function is mentioned in the OpenSSL
object files that you are linking with. (bss_sock.o is the object
file to look at.)

Hi Bodo,

sorry that it took so long, but I had too much work ;-)

However, I tracked the problem down. You were right  in saying that 
OpenSSL libraries were not compiled and linked correctly to the threads 
libraries of AIX. But with the out-of-the box  configuration tool 
(configure) it is nearly impossible to do that on AIX systems. The 
correct compiler to be used is xlc_r which ist the only by IBM supported 
AIX compiler . I just changed the Makefile definition after configuring:

CC=/usr/vac/bin/xlc_r

(this is the standard location of the compiler) and the libraries had 
the correct functions for errno linked (checked it against the 
application and the SSL_ERROR_SYSCALL vanished).

So my question would be as followed: In configure script,

- either check for threads option and existence of xlc_r  and use it. Or,
- (this is my favourite and been used by Apache configure scripts)
  evaluate an environment  variable named CC and use this as the compiler
  to use, regardless what the configure script would evaluate

As I told you, this is an AIX specific problem with threading but may 
occur on other systems as well. So applying the CC variable option is 
the best approach to deal with it (in my opinion).

Thanx anyway for your help,

Ralph


P.S.: If you need evaluations on AIX, feel free to contact me as I got 
access to them.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: [openssl.org #514] Bug in OpenSSL????

2003-02-22 Thread Arne Ansper


 Methods SSL_connect(), SSL_read() and SSL_write() should return
 SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete
 their tasks but the socket couldn't handle all the work.
 
 But instead, the methods return SSL_ERROR_SYSCALL when the underlying
 socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application
 should retry with these functions if it has not been completed, yet)
 from their respective functions (read() and write()).

I had a same error under Linux. The problem was that I had some junk left
in error stack and faulty logic inside SSL_get_error caused the
SSL_ERROR_SYSCALL to be returned.

Try to do ERR_clear_error before SSL_read, SSL_write and SSL_connect see
if it helps.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: [openssl.org #514] Bug in OpenSSL????

2003-02-21 Thread Ralph via RT



Bodo Moeller via RT wrote:

On Wed, Feb 19, 2003 at 06:10:13PM +0100, Ralph via RT wrote:

  

on AIX (64bit) I noticed a major problem with non-blocking sockets. 
Methods SSL_connect(), SSL_read() and SSL_write() should return 
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete 
their tasks but the socket couldn't handle all the work.

But instead, the methods return SSL_ERROR_SYSCALL when the underlying 
socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application 
should retry with these functions if it has not been completed, yet) 
from their respective functions (read() and write()).

For these specific system error numbers, the SSL functions should return 
SSL_ERROR_WANT_* return codes, shouldn't they?



  

PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. 
Funny, isn't it? (But these versions are not supported by IBM anymore!)



It's not SSL_connect() etc. that will return these error codes,
it's SSL_get_error().  But probably you meant that, or you would
not get SSL_ERROR_SYSCALL.

Can you tell what is going on by looking at the definition of
SSL_get_error (ssl/ssl_lib.c) and BIO_sock_should_retry and
BIO_sock_non_fatal_error (crypto/bio/bss_bio.c)?  You might want to
add some debugging output in BIO_sock_non_fatal_error().

  


Hi Bodo,

you're right with the statement about the functions. Sorry, did the work 
a few weeks ago. :-)

I need to further trace it down. Just by inspecting the code I cannot 
see the cause for it. This will take a week 'cause I need access to an 
AIX 5.1 machine and cannot do this here from home.

But so far, I can tell you that when SSL_get_error() returns 
SSL_ERROR_SYSCALL and you inspect errno, it tells EWOULDBLOCK or EAGAIN. 
By  repeating the SSL_* call as long as this condition occurs, I can 
overcome the problem and the SSL handshake and communication works 
perfectly. Oh...it's in a multi-threaded application, too! Maybe this 
helps (OpenSSL compiled with the correct switch for MT - I hope)

I'll get back to you next week (Thursday or Friday)

Ralph


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #514] Bug in OpenSSL????

2003-02-21 Thread Bodo Moeller via RT

Ralph via RT [EMAIL PROTECTED]:

 But so far, I can tell you that when SSL_get_error() returns 
 SSL_ERROR_SYSCALL and you inspect errno, it tells EWOULDBLOCK or EAGAIN. 
 By  repeating the SSL_* call as long as this condition occurs, I can 
 overcome the problem and the SSL handshake and communication works 
 perfectly. Oh...it's in a multi-threaded application, too! Maybe this 
 helps (OpenSSL compiled with the correct switch for MT - I hope)

If OpenSSL is *not* compiler with correct switches for multithreading,
that would explain -- in that case, SSL_get_error() could be reading
the wrong copy of errno and thus not find the EWOULDBLOCK/EAGAIN code.

Here's something to try: find the 'errno' definition for multi-threading
in the system header files, which should involve some function call;
then use 'nm' to see if that function is mentioned in the OpenSSL
object files that you are linking with. (bss_sock.o is the object
file to look at.)


-- 
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]


Re: [openssl.org #514] Bug in OpenSSL????

2003-02-20 Thread Bodo Moeller via RT

On Wed, Feb 19, 2003 at 06:10:13PM +0100, Ralph via RT wrote:

 on AIX (64bit) I noticed a major problem with non-blocking sockets. 
 Methods SSL_connect(), SSL_read() and SSL_write() should return 
 SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete 
 their tasks but the socket couldn't handle all the work.
 
 But instead, the methods return SSL_ERROR_SYSCALL when the underlying 
 socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application 
 should retry with these functions if it has not been completed, yet) 
 from their respective functions (read() and write()).
 
 For these specific system error numbers, the SSL functions should return 
 SSL_ERROR_WANT_* return codes, shouldn't they?

 PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. 
 Funny, isn't it? (But these versions are not supported by IBM anymore!)

It's not SSL_connect() etc. that will return these error codes,
it's SSL_get_error().  But probably you meant that, or you would
not get SSL_ERROR_SYSCALL.

Can you tell what is going on by looking at the definition of
SSL_get_error (ssl/ssl_lib.c) and BIO_sock_should_retry and
BIO_sock_non_fatal_error (crypto/bio/bss_bio.c)?  You might want to
add some debugging output in BIO_sock_non_fatal_error().


-- 
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.org #514] Bug in OpenSSL????

2003-02-19 Thread Ralph via RT

Hi,

on AIX (64bit) I noticed a major problem with non-blocking sockets. 
Methods SSL_connect(), SSL_read() and SSL_write() should return 
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete 
their tasks but the socket couldn't handle all the work.

But instead, the methods return SSL_ERROR_SYSCALL when the underlying 
socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application 
should retry with these functions if it has not been completed, yet) 
from their respective functions (read() and write()).

For these specific system error numbers, the SSL functions should return 
SSL_ERROR_WANT_* return codes, shouldn't they?

Regards

Ralph Schuster

PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. 
Funny, isn't it? (But these versions are not supported by IBM anymore!)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]