On Mon, 15 Jul 2013, Clemens Gruber wrote:

> Thank you! I tried the patch, but the result was the same as before, without
> the verbose option set.

Hm, okay. Thanks for testing, then I guess the problem is different than what
I thought... It is a bit hard to figure out what's going on without the
verbose output but I'll try to give the pcap a second look tonight.

I've written a test case locally to mimic your case but I've not managed to
make it repeat your problem.

> I added some basic printf statements to identify the execution path without
> using -v: https://imageshack.us/a/img23/1328/z4d0.png
> (It's ugly but I hope it helps a little bit. I used the phrases from the
> comments mostly)

Ah, that helps. If you use the names[] array to output the ftpc->state names
instead the plain number it will be easier to follow.

Can you output where in that flow the SIZE commands are sent? I suspect one of
the erroneous ones is sent by ftp_state_quote(). Can you check if that is the
case?

> I still don't understand what's going on: First, the server did not yet
> connect. One statemachine loop later, it did connect and InitiateTransfer is
> called, but somehow ftpc->state is set to 24 (FTP_RETR_SIZE) but not even
> ftp_state_size_resp is called anymore. It's stuck in the statemachine loop.
> But why is it 24, the size of 410k must already be known. (Progress output
> was: "0 410k 0 0 ..")

The state is set to FTP_RETR_SIZE when libcurl has sent a SIZE (before a
pending RETR). It then waits for a response to the SIZE command and it will of
course do that until it gets a response or it times out. 24 is the number for
the FTP_RETR_SIZE state. It seems that it sends the extra SIZE and switches to
this state in a bad/wrong situation and we need to figure out why and adress
it.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html