Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Hello,
I have a Windows client that tries to connect to an SSL server using the
following code :
int status = ::connect( m_sock_fd,(sockaddr *)m_addr,sizeof(m_addr));
if (status == 0)
{
return true;
}
else
{
if (WSAGetLastError()== WSAEWOULDBLOCK)
{
struct timeval tv;
tv.tv_sec = 20;
tv.tv_usec = 0;
fd_set myset;
FD_ZERO(myset);
FD_SET(m_sock_fd, myset);
status = select(m_sock_fd+1, NULL, myset, NULL, tv);
/*some other code here*/
}
else if (WSAGetLastError() == WSAECONNREFUSED)
{
return false;
}
else
{
/*some other code*/
}
}
The socket I am using is NONBLOCKING.
When my SSL server is up and running everything works as expected. When my
SSL server is down, my client times out in 20 seconds because
WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not
listening!
I expect WSAGetLastError() to return WSAECONNREFUSED when my server is not
listening...
The problem I have with this is that my client is forced to wait for 20
seconds before giving up. I expect it to return immediately if the SSL
server is not listening...
Am I missing something? Thanks.
remove
Re: ECDHE help needed, please
On Sat, Aug 22, 2009, Michael D wrote: Thank you for your reply. If I understand correctly, by specifying the 'nocert' option when starting s_server, I am limiting the cipher suites to those without certificates. Otherwise I need to create a certificate and cipher suites that require certificates won't work. Does open ssl support the TLS_ECDH_anon .. cipher suites? Yes the cipherstring AECDH for example will explicitly enable them. Last question. (for now..and thank you) How can a generate an elliptic curve certificate? I tried a few things unsuccessfully to make a certificate, so some tips would really be appreciated. Well you make an EC key and then use that to generate a certificate. You need an EC curve first, you can list supported curves with: openssl ecparam -list_curves Then you can generate a key with: openssl ecparam -genkey -name prime239v3 -out eckey.pem You can also use the universal key generation utility, first dump the curve to a file: openssl genpkey -genparam -algorithm EC -pkeyopt ec_paramgen_curve:prime239v3 -out ecparam.pem Then generate the key: openssl genpkey -paramfile ecparam.pem -out eckey.pem -aes128 That also encrypts the private key and will prompt for a passphrase. It should be possible to do that with one command but there's a bug at present preventing it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
WSAEWOULDBLOCK versus WSAECONNREFUSED
Hello,
I have a Windows client that tries to connect to an SSL server using the
following code :
int status = ::connect( m_sock_fd,(sockaddr *)m_addr,sizeof(m_addr));
if (status == 0)
{
return true;
}
else
{
if (WSAGetLastError()== WSAEWOULDBLOCK)
{
struct timeval tv;
tv.tv_sec = 20;
tv.tv_usec = 0;
fd_set myset;
FD_ZERO(myset);
FD_SET(m_sock_fd, myset);
status = select(m_sock_fd+1, NULL, myset, NULL, tv);
/*some other code here*/
}
else if (WSAGetLastError() == WSAECONNREFUSED)
{
return false;
}
else
{
/*some other code*/
}
}
The socket I am using is NONBLOCKING.
When my SSL server is up and running everything works as expected. When my
SSL server is down, my client times out in 20 seconds because
WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not
listening!
I expect WSAGetLastError() to return WSAECONNREFUSED when my server is not
listening...
The problem I have with this is that my client is forced to wait for 20
seconds before giving up. I expect it to return immediately if the SSL
server is not listening...
Am I missing something? Thanks.
cURL, paypal, and .cer files
I'm trying to integrate with paypal's payflow gateway via cURL. I can't for the life of me get their certificates right and neither paypal or verisign seem to have any idea how to do it. So I'm going to ask here. I basically have a bunch of .cer files that are necessary to connect to payflow.paypal.com. I'm on red hat 9 with apache 1.3. What do I do with those files? I've tried passing them with cURL, and that doesn't seem to be working. How do I add them to apache's keystore? I've been at this for days and nobody seems to know what to do. I'm getting pretty desperate. I can use cURL to connect to any site except the gateway and from what I'm told it's SSL cert related. If anybody has any theories I'd love to hear them. Thanks, Brandon -- View this message in context: http://www.nabble.com/cURL%2C-paypal%2C-and-.cer-files-tp25073071p25073071.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Since you use a nonblocking connect, you're essentially telling the
software you want instant return. Which is what you get.
Given that a TCP connection takes a little time (three network travels
at least), that's definitely more time than you wish to wait given
your nonblocking intent, so the IP stack properly and correctly tells
you it'll take some time before you get the final result --
wouldblock.
The next bit is where I'm a bit rusty (read as: the peculiarities of
WinSock have eroded in my brain), but a glance at the code shows
you're only select()ing for writing and IIRC a finalized non-blocking
connect is equivalent to a 'ready-for-READING' select signal - for
which you are not listening in your select as that argument is NULL.
Hence my advise to also pass your handle in a separate fdset to
select(read), i.e
status = select(m_sock_fd+1, myreadset, mywriteset,
NULL, tv);
(so you can tell upon return which one fired)
and lastly there's the ever-there mind-you nitpick that nonblocking
I/O is well served with a statemachine around it, i.e. a loop, which
tracks the current state of your connections/activity and acts upon
that - it's the long way of saying that a connection may take longer
than 20 seconds to establish, so an if-chain and a long wait isn't the
end-all there, but this nitpick is not your problem. Yet. And the code
structure is not enough to prove there's no statemachine already there
in your code; the current code layout is a (very) weak hint, 's all.
Anyway, a tip: this is generic TCP/IP socket programming we're talking
about here and do yourself a favor and get a hold of the books by W
Richard Stevens (R.I.P.). It's what I grew up with and those books of
his have been among the very few which have never let me down in the
hour of need. They're still 100% applicable and for IPv6 specifics,
there's little enough change that the internet and manpages suffice
for that. They are not WinSock specific, but for that one's
peculiarities (such as the WSASelect limits) there's MSDN.
Take care,
Ger
On Thu, Aug 20, 2009 at 7:58 PM, Md Lazregmdlaz...@gmail.com wrote:
Hello,
I have a Windows client that tries to connect to an SSL server using the
following code :
int status = ::connect( m_sock_fd,(sockaddr *)m_addr,sizeof(m_addr));
if (status == 0)
{
return true;
}
else
{
if (WSAGetLastError()== WSAEWOULDBLOCK)
{
struct timeval tv;
tv.tv_sec = 20;
tv.tv_usec = 0;
fd_set myset;
FD_ZERO(myset);
FD_SET(m_sock_fd, myset);
status = select(m_sock_fd+1, NULL, myset, NULL, tv);
/*some other code here*/
}
else if (WSAGetLastError() == WSAECONNREFUSED)
{
return false;
}
else
{
/*some other code*/
}
}
The socket I am using is NONBLOCKING.
When my SSL server is up and running everything works as expected. When my
SSL server is down, my client times out in 20 seconds because
WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not
listening!
I expect WSAGetLastError() to return WSAECONNREFUSED when my server is not
listening...
The problem I have with this is that my client is forced to wait for 20
seconds before giving up. I expect it to return immediately if the SSL
server is not listening...
Am I missing something? Thanks.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Thank you Ger for your reply. It is true that by using a nonblocking connect I want an instant answer but most importantly I want a correct answer. Using the same code under UNIX I get two instant correct answers: ECONNREFUSED [If my SSL server is down] EINPROGRESS [If my SSL server is up and listening] But under Windows I get the same answer regardless of the state of my SSL server: WSAEWOULDBLOCK My question is why _using the same code_ Windows is returning WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? while UNIX correctly returns ECONNREFUSED... Thanks On Sun, Aug 23, 2009 at 5:04 PM, Ger Hobbelt g...@hobbelt.com wrote: Since you use a nonblocking connect, you're essentially telling the software you want instant return. Which is what you get. Given that a TCP connection takes a little time (three network travels at least), that's definitely more time than you wish to wait given your nonblocking intent, so the IP stack properly and correctly tells you it'll take some time before you get the final result -- wouldblock. The next bit is where I'm a bit rusty (read as: the peculiarities of WinSock have eroded in my brain), but a glance at the code shows you're only select()ing for writing and IIRC a finalized non-blocking connect is equivalent to a 'ready-for-READING' select signal - for which you are not listening in your select as that argument is NULL. Hence my advise to also pass your handle in a separate fdset to select(read), i.e status = select(m_sock_fd+1, myreadset, mywriteset, NULL, tv); (so you can tell upon return which one fired) and lastly there's the ever-there mind-you nitpick that nonblocking I/O is well served with a statemachine around it, i.e. a loop, which tracks the current state of your connections/activity and acts upon that - it's the long way of saying that a connection may take longer than 20 seconds to establish, so an if-chain and a long wait isn't the end-all there, but this nitpick is not your problem. Yet. And the code structure is not enough to prove there's no statemachine already there in your code; the current code layout is a (very) weak hint, 's all. Anyway, a tip: this is generic TCP/IP socket programming we're talking about here and do yourself a favor and get a hold of the books by W Richard Stevens (R.I.P.). It's what I grew up with and those books of his have been among the very few which have never let me down in the hour of need. They're still 100% applicable and for IPv6 specifics, there's little enough change that the internet and manpages suffice for that. They are not WinSock specific, but for that one's peculiarities (such as the WSASelect limits) there's MSDN. Take care, Ger
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Probably the difference is due to timing; to get the connection refused response, the client needs to at least transmit a packet and either never see a response (timing out) or receive a RST or (in some cases) an ICMP host-unreachable packet. Any way, the minimum time required to give you the 'connection refused' response is two network travels at the absolute minimum. Which means: it takes time. 'nonblocking' simply means 'I don't want to wait', so theoretically the IP stack doesn't have to wait even a milli/micro/femtosecond before returning to you. Which is what winsock does: queue request, instant return, hence wouldblock. Apparently (and this can be due to a myriad of reasons) your UNIX box either already 'knows' the server is down or has an IP stack which waits a short while before returning from connect, even in nonblocking conditions, so it is able to deliver a 'connection refused' to you on the initial return. It is true that by using a nonblocking connect I want an instant answer but most importantly I want a correct answer. The answer is correct, because the answer is depending on time. This may sound weird to you as it looks like the whole time/async behaviour pattern here are what's troubling you, but the nonblocking means the 'wouldblock' behaviour is the behaviour you would /expect/ from the system; the fact that the other machine isn't doing this is, at best, something to frown and ponder. /That/ one worries me, not the Win box. How can that machine know /instantaneously/ that the server at other end of the wire is down? There's no paranormal vibe there, so... is it's IP stack implemented to wait /anyway/ (bad!), despite the fact that it knows it's got a nonblocking request from the application? Is it at all /aware/ that this is a nonblocking handle/request here?! Or more obscure and less probable: Is it caching icmp or other previous responses regarding availability of other machines and shortcircuiting the request due to that cached info? etc. (Or is the unix box the server and client both, i.e. connection to localhost or eqv., so the IP stack can short-circuit the request that way?) Your issue is, IMO, not the wouldblock, but the connrefused, which is unexpected for a truely nonblocking socket. I checked my specs, and I was correct in saying that you need to check for a READ event in select() to get a notification about a completed nonblocking connect, both on UNIX and WinSock. While you don't do that (you only ask select() about WRITE events there) the select() will sit an pick it's nose until timeout. Again, nonblocking is you telling the kernel 'go fetch, while I do other stuff at the same time' and the /direct/ return of connrefused only means one thing: the bastard is forcing you to wait anyhow until the system/kernel is done doing its thing, which is /precisely/ what you said, through NONblocking, you do NOT want (the waiting on the call to finish). Either that or the unix box has obtained precognition, which is a bit worrysome in its own way. PS: are you addressing the server by IP number or domain name? In the latter case, have you made sure the DNS request which converts the FQDN to an IP produced a positive result? In other words: is connect being fed a usable IP number and ditto port on both boxes? Are those numbers identical on both boxes? Just making sure here as the immediate connection refused is suspect. On Sun, Aug 23, 2009 at 5:35 PM, Md Lazregmdlaz...@gmail.com wrote: Thank you Ger for your reply. It is true that by using a nonblocking connect I want an instant answer but most importantly I want a correct answer. Using the same code under UNIX I get two instant correct answers: ECONNREFUSED [If my SSL server is down] EINPROGRESS [If my SSL server is up and listening] But under Windows I get the same answer regardless of the state of my SSL server: WSAEWOULDBLOCK My question is why _using the same code_ Windows is returning WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? while UNIX correctly returns ECONNREFUSED... Thanks On Sun, Aug 23, 2009 at 5:04 PM, Ger Hobbelt g...@hobbelt.com wrote: Since you use a nonblocking connect, you're essentially telling the software you want instant return. Which is what you get. Given that a TCP connection takes a little time (three network travels at least), that's definitely more time than you wish to wait given your nonblocking intent, so the IP stack properly and correctly tells you it'll take some time before you get the final result -- wouldblock. The next bit is where I'm a bit rusty (read as: the peculiarities of WinSock have eroded in my brain), but a glance at the code shows you're only select()ing for writing and IIRC a finalized non-blocking connect is equivalent to a 'ready-for-READING' select signal - for which you are not listening in your select as that argument is NULL. Hence my advise to also pass your handle in a separate fdset to
Re: cURL, paypal, and .cer files
On 08/20/2009 10:25 PM, btate wrote: I'm trying to integrate with paypal's payflow gateway via cURL. I can't for the life of me get their certificates right and neither paypal or verisign seem to have any idea how to do it. So I'm going to ask here. I basically have a bunch of .cer files that are necessary to connect to payflow.paypal.com. I'm on red hat 9 with apache 1.3. What do I do with those files? I've tried passing them with cURL, and that doesn't seem to be working. How do I add them to apache's keystore? I've been at this for days and nobody seems to know what to do. I'm getting pretty desperate. I can use cURL to connect to any site except the gateway and from what I'm told it's SSL cert related. If anybody has any theories I'd love to hear them. Thanks, Brandon Hey Brandon, What error messages are you getting back from cURL? Unknown CA? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
Here is what MSDN says:
http://msdn.microsoft.com/en-us/library/ms737625%28VS.85%29.aspx
With a nonblocking socket, the connection attempt cannot be completed
immediately. In this case, *connect* will return SOCKET_ERROR, and *
WSAGetLastError* will return
WSAEWOULDBLOCKhttp://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx#winsock.wsaewouldblock_2.
In this case, there are three possible scenarios:
- Use the
*select*http://msdn.microsoft.com/en-us/library/ms740141%28VS.85%29.aspxfunction
to determine the completion of the connection request by checking
to see if the socket is writeable.
And here is what man connect says on UNIX:
*EINPROGRESS*
The socket is non-blocking and the connection cannot
be completed immediately. It is possible to
select(2) http://man-wiki.net/index.php/2:select or
poll(2) http://man-wiki.net/index.php/2:poll for completion by
selecting the socket for writing. After select(2)
http://man-wiki.net/index.php/2:select indicates
writability, use getsockopt(2)
http://man-wiki.net/index.php/2:getsockopt to read the *SO_ERROR*
option at level *SOL_SOCKET* to determine whether *con-*
*nect*() completed successfully (*SO_ERROR* is zero)
or unsuccessfully (*SO_ERROR* is one of the usual error
codes listed here, explaining the reason for the failure).
So it seems that after select I need to check for writability, which is what
I have been doing.
Just as a test I started checking for read/write/error events by changing my
code to this:
fd_set myrset;
FD_ZERO(myrset);
FD_SET(m_sock_fd, myrset);
fd_set mywset;
FD_ZERO(mywset);
FD_SET(m_sock_fd, mywset);
fd_set myeset;
FD_ZERO(myeset);
FD_SET(m_sock_fd, myeset);
status = select(m_sock_fd+1, myrset, mywset, myeset,
tv);
if (FD_ISSET(m_sock_fd,myrset))
{
cout read set endl flush;
}
if (FD_ISSET(m_sock_fd,mywset))
{
cout write set endl flush;
}
if (FD_ISSET(m_sock_fd,myeset))
{
cout error set endl flush;
}
To my surprise, Windows puts the socket in the error set!!! which to my
knowledge is not documented.
Once select returns after signaling the error set, I call this:
getsockopt(m_sock_fd, SOL_SOCKET, SO_ERROR, (char *)(valopt), lon)
Now valopt is set to WSAECONNREFUSED.
On the UNIX side, you are right, the connect returns EINPROGRESS, then the
select signals the write set [ as documented ], the getsockopt then gives me
ECONNREFUSED.
I think this is a bug on Windows or at least the documentation is wrong. It
should say to check on the error set not on the write set using the select
call...
Thanks. I have solved my problem.
On Sun, Aug 23, 2009 at 6:20 PM, Ger Hobbelt g...@hobbelt.com wrote:
Probably the difference is due to timing; to get the connection
refused response, the client needs to at least transmit a packet and
either never see a response (timing out) or receive a RST or (in some
cases) an ICMP host-unreachable packet. Any way, the minimum time
required to give you the 'connection refused' response is two network
travels at the absolute minimum. Which means: it takes time.
'nonblocking' simply means 'I don't want to wait', so theoretically
the IP stack doesn't have to wait even a milli/micro/femtosecond
before returning to you. Which is what winsock does: queue request,
instant return, hence wouldblock. Apparently (and this can be due to a
myriad of reasons) your UNIX box either already 'knows' the server is
down or has an IP stack which waits a short while before returning
from connect, even in nonblocking conditions, so it is able to deliver
a 'connection refused' to you on the initial return.
It is true that by using a nonblocking connect I want an instant answer
but
most importantly I want a correct answer.
The answer is correct, because the answer is depending on time.
This may sound weird to you as it looks like the whole time/async
behaviour pattern here are what's troubling you, but the nonblocking
means the 'wouldblock' behaviour is the behaviour you would /expect/
from the system; the fact that the other machine isn't doing this is,
at best, something to frown and ponder. /That/ one worries me, not the
Win box.
How can that machine know /instantaneously/ that the server at other
end of the wire is down? There's no paranormal vibe there, so... is
it's IP stack implemented to wait /anyway/ (bad!), despite the fact
that it knows it's got a nonblocking request from the application? Is
it at all /aware/ that this is a
RE: WSAEWOULDBLOCK versus WSAECONNREFUSED
Md Lazreg wrote: When my SSL server is up and running everything works as expected. When my SSL server is down, my client times out in 20 seconds because WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not listening! I expect WSAGetLastError() to return WSAECONNREFUSED when my server is not listening... The problem I have with this is that my client is forced to wait for 20 seconds before giving up. I expect it to return immediately if the SSL server is not listening... Am I missing something? Thanks. Why? The SSL server might be restarting. Perhaps it will be listening again in a second or two. It takes as long as it takes to ensure that the server is not listening and will not resume listening. This is one of the differences between Windows and traditional UNIX systems. On Windows, if a server is overloaded, it refuses connections rather than silently ignoring them. As a result, when a client gets a connection refused, it cannot assume the server is not listening. It's possible the server is overloaded. So it has to try again, which takes some time. My question is why _using the same code_ Windows is returning WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? while UNIX correctly returns ECONNREFUSED... Because Windows cannot tell whether your server is down or overloaded. UNIX assumes that it is down, which may or may not be correct. The Windows client behavior you are seeing is correct, but only because it is assuming Windows server behavior that is incorrect. The UNIX behavior is incorrect -- it cannot be sure your server is actually down, but assumes so anyway -- but only because it assumes the server will behave correctly. Because Windows servers do not behave correctly, Windows clients are forced to behave incorrectly. I have yet to figure out why things are this way, but this is the way they are. It appears to be a deliberate Microsoft decision that we all have to live with. The summarize: When Windows server are overloaded, they reject connections rather than ignoring them. Thus, a client that sees a rejected connection cannot be sure the server is not running -- it could just be overloaded. (So you are correctly told the connection could not be made at that time, but might succeed later.) It's also possible the server is restarting, and will be accepting connections again in a second or two. The Windows client checks for this as well. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
