cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[curl:bugs] #1310 TFTP connection takes CURLOPT_TIMEOUT seconds to time out, not CURLOPT_CONNECTTIMEOUT

From: Daniel Stenberg <bagder_at_users.sf.net>
Date: Tue, 03 Dec 2013 21:24:44 +0000

Hm. TFTP is UDP so it has no real connection, so thus a connection timeout is a bit of a funny concept there. It will still be considered for what's done before the actual data transfer, but after the name resolving is done there's no more connection being done but it switches immediately to transfer...

I'm not sure I have a better fix for this than documenting this better. Do you?

---
** [bugs:#1310] TFTP connection takes CURLOPT_TIMEOUT seconds to time out, not CURLOPT_CONNECTTIMEOUT**
**Status:** open-confirmed
**Labels:** TFTP 
**Created:** Tue Dec 03, 2013 08:57 PM UTC by James Dury
**Last Updated:** Tue Dec 03, 2013 08:57 PM UTC
**Owner:** Daniel Stenberg
Problem occurs when using libcurl to attempt to connect to a non-existent TFTP server, with CURLOPT_CONNECTTIMEOUT < CURLOPT_TIMEOUT. 
libcurl version libcurl/7.33.0
CURLOPT_URL=tftp://192.168.0.3/somefile (server doesn't exist)
CURLOPT_CONNECTTIMEOUT=10
CURLOPT_TIMEOUT=20
When calling curl_easy_perform:
* About to connect() to 192.168.0.3 port 69 (#0)
*   Trying 192.168.0.3...
* Adding handle: conn: 0xa02d418
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0xa02d418) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.0.3 (192.168.0.3) port 69 (#0)
* getpeername() failed with errno 107: Transport endpoint is not connected
* set timeouts for state 0; Total 10, retry 3 maxtry 3
< 10 seconds later... >
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* TFTP response timeout
* Operation timed out after 20002 milliseconds with 0 out of 0 bytes received
* Closing connection 0
**curl_easy_perform** returned CURLE_OPERATION_TIMEDOUT after 20 seconds.
What happens after the 10 second timeout is that **tftp_multi_statemach** returns CURLE_OPERATION_TIMEDOUT to **tftp_doing** each time it is called, but **tftp_doing** overwrites the result with the result from **Curl_speedcheck**, which returns OK.
Forcing **tftp_doing** to return the CURLE_OPERATION_TIMEDOUT produces the correct result, which is that **curl_easy_perform** returns CURLE_OPERATION_TIMEDOUT after 10 seconds. I don't know if this is the correct approach.
May be related to http://sourceforge.net/p/curl/bugs/856/ which is a similar bug with FTP.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.
Received on 2013-12-03

These mail archives are generated by hypermail.

donate! Page updated May 06, 2013.
web site info

File upload with ASP.NET