RE: TFTP timeout interval header

From: Dan B via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 17 Dec 2021 11:53:25 -0800

> > 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?
>

This is how the code works in the latest release. No changes were made to the code.

> > 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.

The issue is that option=(timeout) is tied to connect-timeout parameter. For example (just the relevant parts):

# curl -v -T ./Up1M.bin --url tftp://172.16.9.2:69/Up1M.bin.test --connect-timeout 10
* set timeouts for state 0; Total 10, retry 3 maxtry 3
* got option=(timeout) value=(3)


# curl -v -T ./Up1M.bin --url tftp://172.16.9.2:69/Up1M.bin.test --connect-timeout 60
* set timeouts for state 0; Total 60, retry 5 maxtry 12
* got option=(timeout) value=(5)


# curl -v -T ./Up1M.bin --url tftp://172.16.9.2:69/Up1M.bin.test --connect-timeout 500
* set timeouts for state 0; Total 500, retry 10 maxtry 50
* got option=(timeout) value=(10)


# curl -v -T ./Up1M.bin --url tftp://172.16.9.2:69/Up1M.bin.test --connect-timeout 1500
* set timeouts for state 0; Total 1500, retry 30 maxtry 50
* got option=(timeout) value=(30)

option=(timeout) is always set to the value of retry, and retry is calculated based on the --connect-timeout parameter.
If I want to set the server timeout option to 255 (which is the maximum the RFC allows) I have to set a connect-timeout of 12750.

>
> > 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!
>

I investigated this further, and changing the option=(timeout) to use the connect-timeout value seems to work best. Set to 255 if still over the limit. For example:
        --connect-timeout 60
        would set option=(timeout) to 60.


I've attached the patch with the change I tested here.

> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html

Received on 2021-12-17