Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: TFTP timeout interval header
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 10 Dec 2021 15:35:01 +0100 (CET)
On Thu, 9 Dec 2021, Daniel Belz via curl-users wrote:
> I'm trying to use cURL's tftp client over a cellular connection that can
> show very long latency sometimes. To avoid timing out the connection, I have
> to setup the timeout option to a large value - for example, 30 seconds.When
> using curl client, the TFTP timeout option is calculated based on the
> parameter --connection-timeout.
I'm not following. Are you saying this is how it works after some changes of
yours or that it works like this in the latest release?
> To get the negotiated timeout to be 30 seconds, I need to set connection
> timeout to 1500, which causes the the issue that a connection failure to
> retry 50 times:
> # curl -v -T ./Up1M.bin --url tftp://172.16.9.2:79/Up1M.bin --retry 3
> --connect-timeout 1500
That is not following how those options are documented to work.
--connect-timeout is for maximum time to allow "the connection" to happen,
which in the TFTP case is a bit vague but surely has passed once at least one
TFTP package has been transmitted both ways. The max time the code is allowed
to remain in TFTP_STATE_START seems reasonable.
--retry is for retrying a *failed transfer* when that transfer fails with a
"transient error", which I'm not sure there is any when it comes to TFTP?
> According to the RFC2349 (https://datatracker.ietf.org/doc/html/rfc2349),
> timeout option must accept values between 1 and 255. While this is possible
> by increasing the value for connect-timeout, to achieve a value of 255, I'd
> have to set connect-timeout to 12750. Changing the retry_max calculation to
> divide by 255 (maximum timeout allowed per RFC) and retry_max lower limit to
> 1 would solve this specific problem.
I don't understand this.
> Are there any reasons why the ACK repost is 5 seconds, and retry_max lower
> limit is 3?
We/I figured they were sensible values.
> If not, I can submit a patch to update these values.
Please do, then perhaps I will understand your intensions better!
Date: Fri, 10 Dec 2021 15:35:01 +0100 (CET)
On Thu, 9 Dec 2021, Daniel Belz via curl-users wrote:
> I'm trying to use cURL's tftp client over a cellular connection that can
> show very long latency sometimes. To avoid timing out the connection, I have
> to setup the timeout option to a large value - for example, 30 seconds.When
> using curl client, the TFTP timeout option is calculated based on the
> parameter --connection-timeout.
I'm not following. Are you saying this is how it works after some changes of
yours or that it works like this in the latest release?
> To get the negotiated timeout to be 30 seconds, I need to set connection
> timeout to 1500, which causes the the issue that a connection failure to
> retry 50 times:
> # curl -v -T ./Up1M.bin --url tftp://172.16.9.2:79/Up1M.bin --retry 3
> --connect-timeout 1500
That is not following how those options are documented to work.
--connect-timeout is for maximum time to allow "the connection" to happen,
which in the TFTP case is a bit vague but surely has passed once at least one
TFTP package has been transmitted both ways. The max time the code is allowed
to remain in TFTP_STATE_START seems reasonable.
--retry is for retrying a *failed transfer* when that transfer fails with a
"transient error", which I'm not sure there is any when it comes to TFTP?
> According to the RFC2349 (https://datatracker.ietf.org/doc/html/rfc2349),
> timeout option must accept values between 1 and 255. While this is possible
> by increasing the value for connect-timeout, to achieve a value of 255, I'd
> have to set connect-timeout to 12750. Changing the retry_max calculation to
> divide by 255 (maximum timeout allowed per RFC) and retry_max lower limit to
> 1 would solve this specific problem.
I don't understand this.
> Are there any reasons why the ACK repost is 5 seconds, and retry_max lower
> limit is 3?
We/I figured they were sensible values.
> If not, I can submit a patch to update these values.
Please do, then perhaps I will understand your intensions better!
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-12-10