On Wed, 12 Nov 2008, Andreas Wurf wrote:

> What bothers me: Why does libcurl send out the PASV when the "226 Transfer
> complete" for the previous transfer has not been received yet? A complete
> sequence looks like:
>
> ----------------------------------<snip>----------------------------------
> PASV
> 227 Entering Passive Mode (1.2.3.4,244,77).
> STOR file21
> 150 Opening BINARY mode data connection for file21
> 226 Transfer complete.
> ----------------------------------</snip>---------------------------------

Aah. I didn't notice that. Good catch! Indeed a clear hint.

> Could it be that libcurl somehow skipped or "ate" the "226" Response and
> instead continues with the next file - which will surely break the
> protocol's control flow?

It is indeed strange that the 226 didn't appear, but since you're looking at
wireshark data it truly is the server that doesn't send any.

The question is then why libcurl continues at all and doesn't simply wait for
it. The fact that it then goes on to the DOING state also implies that it acts
as if it had gotten the 226.

> PASV
> 227 Entering Passive Mode (1,2,3,4,196,244).
> TYPE I
> 200 Type set to I
> STOR file01
> 150 Opening BINARY mode data connection for file01
> CWD / // <-- stuck here!
> ----------------------------------</snip>---------------------------------
>
> As you see, the hang is not after a PASV but after a CWD command. But in
> this case too, the "226 Transfer complete" of the previous transfer is not
> there. Different Symptoms of the same Problem?

It certainly looks like the same "behave as if the 226 has arrived even though
it hasn't" problem.

Is the file sent on this last STOR of a particular size? or is there any other
timing in common that's detectable?

I think all data now points to a flaw in lib/ftp.c:ftp_done(). The problem is
that we don't have any good way to trigger a break-point in there to see when
the mistake is performed as we don't really know until it is too late. Perhaps
adding some debug output of some variables in that function could be a
start...

-- 
  / daniel.haxx.se