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

Reply via email to