This may be a stretch, but did you confirm the socket is within the
range of sockets your platform allows you to 'select' on? For example,
Linux by default doesn't permit you to 'select' on socket numbers 1,025
and up, though you can have more than 1,024 file descriptors in use
without a
On 11/2/2010 6:25 PM, Md Lazreg wrote:
r=select(m_sock_fd + 1, fds, 0, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed
out with EAGAIN try again*/
{
r = 1;
}
This code is broken. If 'select' returns zero, checking errno is
On Wed, Nov 3, 2010 at 9:12 AM, David Schwartz dav...@webmaster.com wrote:
On 11/2/2010 6:25 PM, Md Lazreg wrote:
r=select(m_sock_fd + 1, fds, 0, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed
out with EAGAIN try again*/
{
r = 1;
From: owner-openssl-us...@openssl.org On Behalf Of Sam Jantz
Sent: Tuesday, 07 September, 2010 17:29
Where are SSL_accept, and SSL_connect defined? Specifically
for TLSv1, and SSLv3 connections. I found the definition
in ssl_lib.c but then that calls
Original message
Date: Fri, 30 Mar 2007 12:01:54 -0700
From: David Schwartz [EMAIL PROTECTED]
Subject: RE: SSL_connect and SSL_accept
To: openssl-users@openssl.org
So what you are saying is the scenario we have been discussing so far is
possible ONLY in case of memory allocation
[EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying transport connection, and
if that has
-
From: Gayathri Sundar [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Friday, March 30, 2007 9:25 AM
Subject: Re: SSL_connect and SSL_accept
I am quite clear with your problem and am not confused. The only point I
have been stressing from beginning is that SSL_connect due to WHATEVER
error
snip
I have spent quite some time with SSL_connect, and apart from tcp level
socket failures (transient/fatal) and SSL Handshake failures it cannot
return error, so ur case is NOT POSSIBLE unless the HOST has run out of
memory wherein Openssl_malloc itself fails. So I dont suppose you need to
So what you are saying is the scenario we have been discussing so far is
possible ONLY in case of memory allocation issues NOT OTHERWISE.
I guess I will have a look at the SSL_connect code before I just
trust this
:-)
I would still recommend coding to handle this case. Perhaps the next
I am unable to think of a scenerio why ur case is possible unless some
serious network congestion has developed and pkts were lost..i dont see
how..but the experts might able to give u a better idea.
You get a SYN, send a SYN ACK, other side sends an ACK, then the other
side's Internet
Yes, I agree with you, but then why would the CLIENT get an ERROR?
2) The client calls SSL_connect(). The underlying socket is in blocking
mode
3) SSL_connect() returns error.
4) The server does not notice this, and continues to wait in SSL_accept().
if SSL_connect indeed has returned with
with respect to the current thread. So I will
send a new post for that.
Thank you everyone for responding.
~ Urjit
- Original Message -
From: Gayathri Sundar [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Thursday, March 29, 2007 1:02 PM
Subject: RE: SSL_connect and SSL_accept
Yes, I agree
Urjit Gokhale wrote:
I believe you are confusing tcp/ip connection establishment and SSL session
establishment.
... and you should also remember that a reliable transport is a
prerequisite for tls.
The problem may occur when:
1) Server is waiting for first SSL handshake packet in
: Gayathri Sundar [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying transport connection
]
To: openssl-users@openssl.org
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying transport connection, and
if that has problems, SSL has
I am wondering if the following scenario possible:
1) The server calls SSL_accept(). The underlying socket is in blocking mode
2) The client calls SSL_connect(). The underlying socket is in blocking
mode
3) SSL_connect() returns error.
4) The server does not notice this, and continues to wait in
If the scenario mentioned above is possible, then the server
will be blocked in the SSL_accept() (until the underlying tcp
connection is broken) and hence wont be able to service other
clients' connection requests
This is the Toyota Principle, you asked for it, you got it. If you don't
want
If the scenario mentioned above is possible, then the server
will be blocked in the SSL_accept() (until the underlying tcp
connection is broken) and hence wont be able to service other
clients' connection requests
This is the Toyota Principle, you asked for it, you got it. If you don't
18 matches
Mail list logo
