Hi all,
I would like to add an update to this issue.
On Mac OSX 10.5.8, I face this issue even on a single connect.
I connect to my server and mainly upload lots of data. Data from server is
very less.
In the log presented below data sent is 54253805 bytes through the Socket in
50 minutes.

The following is the brief sequence of steps:

curl_global_init();
easyHandle = curl_easy_init();
//set ssl parameters, CONNECT_ONLY, URL etc on easyHandle
curl_easy_perform();
curl_easy_getinfo(CURLINFO_LASTSOCKET);
//perform read/write operations on the Socket
//Here I wait on select for the socket to be readable/writable and perform
the actual data read/write using curl_easy_send/recv functions.
curl_easy_cleanup()
curl_global_cleanup()

After connecting and send/recv for around 15-20 minutes, suddenly the socket
closes with the same error as in the initial mail, with curl code 1
(Unsupported Protocol). Curl Debug logs also specify the "Failed to get last
socket" error.
The time is varying and in the log given below, the application ran for 50
minutes before crashing, but generally it fails in around 15-20 minutes.
I was trying to follow this thread for updates but, I have to admit that
this is getting pretty technical (it has to) and internal to CURL and I do
not have the kind of exposure to grasp all the content being discussed. Felt
may be this update could give you some more information.

The curl version information and CURL logs are pasted below for reference.
----Begin log information

2009-08-28 18:07:39.082 TestApp[16561:613] Curl Version Info:
    libcurl/7.19.3 OpenSSL/0.9.7l zlib/1.2.3
2009-08-28 18:07:39.191 TestApp[16561:613] CURLINFO - About to connect()
to 192.168.2.33 port 443 (#0)
2009-08-28 18:07:39.192 TestApp[16561:613] CURLINFO - Trying
192.168.2.33...
2009-08-28 18:07:39.192 TestApp[16561:613] CURLINFO - TCP_NODELAY set
2009-08-28 18:07:39.193 TestApp[16561:613] CURLINFO - connected
2009-08-28 18:07:39.194 TestApp[16561:613] CURLINFO - Connected to
192.168.2.33 (192.168.2.33) port 443 (#0)
2009-08-28 18:07:39.217 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Client hello (1):
2009-08-28 18:07:39.219 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Server hello (2):
2009-08-28 18:07:39.220 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, CERT (11):
2009-08-28 18:07:39.221 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Request CERT (13):
2009-08-28 18:07:39.221 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Server finished (14):
2009-08-28 18:07:39.222 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, CERT (11):
2009-08-28 18:07:39.224 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Client key exchange (16):
2009-08-28 18:07:39.235 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, CERT verify (15):
2009-08-28 18:07:39.236 TestApp[16561:613] CURLINFO - SSLv3, TLS change
cipher, Client hello (1):
2009-08-28 18:07:39.238 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Finished (20):
2009-08-28 18:07:39.242 TestApp[16561:613] CURLINFO - SSLv3, TLS change
cipher, Client hello (1):
2009-08-28 18:07:39.242 TestApp[16561:613] CURLINFO - SSLv3, TLS
handshake, Finished (20):
2009-08-28 18:07:39.243 TestApp[16561:613] CURLINFO - SSL connection
using AES256-SHA
2009-08-28 18:07:39.245 TestApp[16561:613] CURLINFO - Server
certificate:
2009-08-28 18:07:39.246 TestApp[16561:613] CURLINFO - subject:
C=US, ST=Oregon, L=Portland, CN=devnull.org
2009-08-28 18:07:39.247 TestApp[16561:613] CURLINFO - start date:
2008-12-24 12:19:40 GMT
2009-08-28 18:07:39.248 TestApp[16561:613] CURLINFO - expire date:
2009-12-24 12:19:40 GMT
2009-08-28 18:07:39.249 TestApp[16561:613] CURLINFO - common name:
devnull.org (does not match '192.168.2.33')
2009-08-28 18:07:39.250 TestApp[16561:613] CURLINFO - issuer: C=US,
ST=Oregon, L=Portland, CN=devnull.org
2009-08-28 18:07:39.251 TestApp[16561:613] CURLINFO - SSL
certificate verify result: self signed certificate (18), continuing anyway.
2009-08-28 18:07:39.253 TestApp[16561:613] CURLINFO - Connection #0 to
host 192.168.2.33 left intact
2009-08-28 18:57:39.719 TestApp[16561:3e07] CURLINFO - SSLv3, TLS alert,
Client hello (1):
2009-08-28 18:57:39.725 TestApp[16561:3e07] CURLINFO - Failed to get
recent socket
2009-08-28 18:57:39.777 TestApp[16561:3e07] CURLINFO - Closing
connection #0
2009-08-28 18:57:39.778 TestApp[16561:3e07] CURLINFO - SSLv3, TLS alert,
Client hello (1):

-------end log information

Thanks
Jogeshwar Karthik Akundi

On Thu, Aug 20, 2009 at 11:16 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Thu, 20 Aug 2009, koettermarkus_at_gmx.de wrote:
>
> libcurl doesn't respect SSL_ERROR_WANT_* at all, no, but the impact of not
>>> respecting that is a short burst of too-much-looping and I've not yet seen
>>> anyone badly damaged by that. This flaw has existed since forever in
>>> libcurl.
>>>
>>
>> Recycling ssl connections without proper shutdown works?
>>
>
> Sorry, what is that referring to exactly? libcurl can re-use SSL
> connections, yes, but that's not what you're asking about is it?
>
> Current openssl documentation is pretty complete to do all required
>> actions, but it is a large, and easy to misunderstand.
>>
>
> I disagree. There are numerous undocumented or very scarcely documented
> functions. Just look for example how the RAND_screen() issue appeared just a
> short while ago: undocumented side-effects. But of course, it's just another
> open source projects so it is nobody's and everybody's fault so we can all
> help out and fix this and I can admit to not having done a lot about it.
>
> Really? NSS and gnutls also provide fine non-blocking functionality.
>>>
>>
>> I've never seen gnutls nonblocking code working
>>
>
> Apart from the libcurl implementation limitations, what's not working
> non-blocking in our current gnutls layer?
>
> --
>
> / daniel.haxx.se
>
Received on 2009-08-28