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 both the SSL_connect and the SSL_accept calls.
This looks to me as a deadlock situation where both my server and my client
are wanting to do a READ until both of them timeout!
Can someone please suggest to me what is wrong with the above code and how
is this deadlock possible?? I am using
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
s-method-ssl_accept(s). From here the only mention I could find of an
ssl3_accept is in s3_srvr.c which to my understanding is not part
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 s-method
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
: 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 it returns a failure to the calling application, the peer WILL know
for the simple fact that a socket send cannot fail unless
-
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 ERROR
in SENDING the
Handshake message but never receive any ACK, so the TCP will endup doing
retransmissions. SSL_connect WILL NOT return with ERRORS in this case.
Its all blocked, I agree, but YOUR scenerio of SSL_CONNECT failing and
SSL_ACCEPT not knowing that CANNOT happen. SSL_connect will SUCCEED and
BLOCK
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
Hello,
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
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
connect to itself.
I created a Certificate Authority and the certificates described in Network
Security with OpenSSL, Viega et al, chapter 5. I then used these certificates
in the application. However, OpenSSL has problems with these certificates in
both SSL_connect() and SSL_accept().
Here
Title: Fork() after a good SSL_connect and SSL_accept - does it work?
I have a closed ('closed' in the sense that produce the client and the server applications) client/server application which optionally uses SSL to secure the session. It's a mature propretiary client/server protocol which
I've got a client/server pair in which the server forks for each
connection. It calls fork() after the accept() returns and then
does all the ssl gymnastics in the child process. Other than probably
being a bit more costly than using a thread, it works fine.
Paul Allen
mclellan, dave wrote:
I
Hi again,
My problem with SSL_connect and SSL_accept that I
was having yesterday has been tracked down to this...
ssl23_get_server_hello
ssl23_read_bytes...
and then ...
int ret=0;
if (out != NULL){#ifndef
BIO_FDclear_socket_error();ret=readsocket(b-num,out,outl);
I've made a few
25 matches
Mail list logo
