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 pro
On Wed, Nov 3, 2010 at 9:12 AM, David Schwartz 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;
>>
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
I have an SSL client that connects to an SSL server. The server is able to
process 1000s of clients just fine on a variety of platforms
[Window/Linux/HP/Solairs] for long periods of time.
The problem that is driving me nuts is that from time to time like once
every 24 hours some client fails to co
> 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->meth
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 of the
l
Original message
>Date: Fri, 30 Mar 2007 12:01:54 -0700
>From: "David Schwartz" <[EMAIL PROTECTED]>
>Subject: RE: SSL_connect and SSL_accept
>To:
>
>
>> So what you are saying is the scenario we have been discussing so far is
>> possibl
> 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 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
worry ab
ure (timeout),
it would report failure to the client
~ Urjit
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
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
ha
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
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 tran
Sundar" <[EMAIL PROTECTED]>
To:
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 pr
: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
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,
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 SSL_a
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:
Sent: Thursday, March 29, 2007 1:02 PM
Subject: RE: SSL_connect and SSL_accept
Yes, I agr
send a
new post for that.
Thank you everyone for responding.
~ Urjit
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 1:02 PM
Subject: RE: SSL_connect and SSL_accept
Yes, I agree with you, but then why would the CLIENT g
Hi,
> > 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
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 ER
> 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 conn
>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
> > 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
> 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
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 wa
ation 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_a
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 hav
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/
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_FD clear_socket_error(); ret=readsocket(b->num,out,o
27 matches
Mail list logo
