Menu ▾ ▴

#1269 TFTP does not stop if rate is below low-speed-limit

closed-fixed
Daniel Stenberg
None
5
2014-08-11
2013-08-19
Jo3
No

TFTP transfers do not timeout when data rate is below CURLOPT_LOW_SPEED_LIMIT for CURLOPT_LOW_SPEED_TIME.

Looks like Curl_speedcheck() needs to be called in tftp.c:tftp_receive_packet().

Tested by initiating a transfer with curl binary running as tftp client. Then I pulled the ethernet cable to simulate network dis-connectivity. The transfer does not timeout within the timeframe specified by CURLOPT_LOW_SPEED_TIME.

curl 7.32.0 (x86_64-unknown-linux-gnu) libcurl/7.32.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: Debug TrackMemory IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

1 Attachments
0001-TFTP-acknowledge-the-LOW_SPEED_-options.patch

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2013-08-19

    Thanks for the report. What about a patch like the one I attach here?

     

    • Jo3

      Jo3 - 2013-08-20

      That patch does not fix it. tftp_receive_packet() looks like it only gets called when data is received. In my test case, there is NO data passing and so that function never gets called which in turn means Curl_speedcheck() will never get called.

      Is there a facility to periodically invoke Curl_speedcheck() from another context?

       

  • Daniel Stenberg

    Daniel Stenberg - 2013-08-19
    • status: open --> open-confirmed
    • assigned_to: Daniel Stenberg
     

  • Daniel Stenberg

    Daniel Stenberg - 2013-08-21

    I guess I'll just have to make sure I can write up a test case for this to repeat it myself, and then make sure I get a correct fix. I'll get working on it soonish.

     

  • Daniel Stenberg

    Daniel Stenberg - 2013-08-22
    • status: open-confirmed --> closed-fixed
     

  • Daniel Stenberg

    Daniel Stenberg - 2013-08-22

    I improved the TFTP test server to be able to do a test for this. Then I wrote up test 1238 and could repeat the problem. Then I committed a fix that made test 1238 run fine. Then I pushed the lot to git. The fix is in commit 4bea91fc: https://github.com/bagder/curl/commit/4bea91fc6773

    Thanks for the report, case closed!