#922 cUrl sends invalid timeout value

[Eric Mertens]

Due to the bug I previously reported cUrl is now sending invalid values for the timeout. Previously these invalid value were on the wrong key and were ignored.

http://tools.ietf.org/html/rfc2349

#secs
The number of seconds to wait before retransmitting, specified
in ASCII. Valid values range between "1" and "255" seconds,
inclusive. This is a NULL-terminated field.

cUrl sends 300 for the retransmit interval, though I suspect something like 1 or 5 seconds would be more reasonable. 5 minutes seems a bit high!

[Daniel Stenberg]

I'm not an TFTP expert so I'm not completely clear over what the timeout is used for. But what about a patch like this:

--- a/lib/tftp.c
+++ b/lib/tftp.c
@@ -526,8 +526,8 @@ static CURLcode tftp_send_first(tftp_state_data_t *state, tf
TFTP_OPTION_BLKSIZE);
sbytes += tftp_option_add(state, sbytes,
(char *)state->spacket.data+sbytes, buf );
- /* add timeout option, this is the max time the session may live */
- snprintf( buf, sizeof(buf), "%d", state->retry_time*state->retry_max );
+ /* add timeout option */
+ snprintf( buf, sizeof(buf), "%d", state->retry_time );
sbytes += tftp_option_add(state, sbytes,
(char *)state->spacket.data+sbytes,
TFTP_OPTION_INTERVAL);

[Eric Mertens]

I think that this patch makes sense. It is my understanding that the "timeout" option negotiates the amount of time for client and server to wait for a response before retransmitting a single packet.

Alternatively, it might make sense to not specify the timeout interval at all, since before that recent patch curl was not actually specifying a timeout interval and everyone was happy. (This would enable the elimination of the relevant code as a server should never propose an option that the client did not.)

[Daniel Stenberg]

Thanks a lot for your report. I decided to leave the timeout option in there just to still allow it to be set and to make it easier for future tweaks, should they become necessary. committed and pushed to git now!