Bugs item #3429299, was opened at 2011-10-27 05:24
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3429299&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: ftp
Group: bad behaviour
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gokhan Sengun (gseng)
Assigned to: Daniel Stenberg (bagder)
Summary: Active FTP hangs if server does not open data connection

Initial Comment:
Working with libcurl version 7.22.0

An active FTP connection is setup with multi interface. Sometimes it is just not possible for FTP server to connect to the port given by the client with PORT or EPRT command. Server could send 425 Can't open data connection or be just dead in the middle of transaction.

Killing the executable (and having a coredump) shows that AllowServerConnect function just looks for notifications in the data connection however control connection should also be observed to get errors like the ones described above.

Server log:

(192.168.0.90)> STOR cmd_input.txt
(192.168.0.90)> 150 Opening data channel for file transfer.
(192.168.0.90)> 425 Can't open data connection.
(192.168.0.90)> 421 Connection timed out.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-12-20 15:11

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: 2011-10-29 14:37

Message:
Yang Tse has started working on adjusting the test FTP server code to make
it able to run exactly your case and once we have a test case in the curl
test suite that can repeat this case I intend to work on it.

----------------------------------------------------------------------

Comment By: Gokhan Sengun (gseng)
Date: 2011-10-29 10:25

Message:
The test code works fine for me too with a Linux FTP host running on the
local machine. Original problem was created with a code using libcurl
running on Linux machine which connects to an FTP server running on a
Windows host.

I guess Linux FTP server gets the last ACK from libcurl and immediately set
the port's state to "CLOSED" without putting it on "TIME_WAIT" and wait
enough time (2 minutes) to make sure that the remote party stopped playing
the TCP/IP game.

I again guess that my Filezilla FTP server running on Windows is not clever
enough to wait for the last ACK from the FTP client and therefore windows
TCP stack puts the port in "TIME_WAIT" state to make sure nobody else use
this port to assure reliability. So this seems clearly Filezilla Server's
bug if not Windows :-)

Regardless of the rootcause of the problem, I believe libcurl should no
longer wait server to connect from data port if server sent a 4xx command
from the control channel.

Thanks for your attention on this Daniel!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-10-27 14:27

Message:
Your test code works fine for me, doing the 3 consecutive transfers from my
local ftp server. Repeatedly. on Linux...

----------------------------------------------------------------------

Comment By: Gokhan Sengun (gseng)
Date: 2011-10-27 12:50

Message:
Hi Daniel,

Test case could be easily written. When an active FTP connection is made,
Server side socket stays in TIME_WAIT state for the remote port X which is
used in the previous data connection between the client and the server. If
another FTP data connection is to be established before Server socket times
out (default to 2 minutes), server fails to connect to the port opened by
FTP client.

So repeating triggering two active FTP downloads/uploads, the second
connection should exhibit the behaviour.

Attaching the test code.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-10-27 09:19

Message:
Hm, this does indeed warrant some kind of fix.

Have you looked into producing a test case that repeats this case?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3429299&group_id=976
Received on 2011-12-21