Bugs item #3006786, was opened at 2010-05-25 13:03
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3006786&group_id=976
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SCP/SFTP
Group: wrong behaviour
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jason McDonald (jasonmcdonald)
Assigned to: Daniel Stenberg (bagder)
Summary: SFTP does not terminate on timeout when link is lost
Initial Comment:
While doing some tests on a i486 embedded device I stumbled upon a litle bug regarding a connection loss. When I unplug the network cable during a SFTP-Download, the connection will only be terminated after the general ip_conntrack_tcp_timeout_time_wait has been reached. This makes the max-timeout-variable somehow irrelevant for batch jobs in an instable network environment. I propose the following patch (s. file attachement). Some Details: Used Zenwalk 6.2 Core on a i486-pc-linux-gnu system. The curl version was 7.20.1
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Date: 2010-06-02 23:37
Message:
Thanks for the report, this problem is now fixed in the git repository.
To try it out, you either checkout/update your git clone:
http://curl.haxx.se/source.html
or you try tomorrow's daily snapshot: http://curl.haxx.se/snapshots/
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Date: 2010-05-27 22:12
Message:
Thanks a lot for your help. I see exactly how this is an actual bug, and I
used your suggested patch as inspiration and wrote up my own alternative
fix. What do you say about the ssh-timeout.patch I've attached here?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3006786&group_id=976
Received on 2010-06-02