Daniel Stenberg wrote:
> Can you repeat this with any certainty?

Yes! Furthermore, have some additional information:

1) The server is FTP on OS/400 (again!). It does not crash after QUIT;
it sends back the reply and closes the connection with a TCP packet with
FIN+ACK+PSH flags (probably characteristic of the OS/400 IP stack).
2) Running the client on Linux is OK. I see in Wireshark that Linux
answers to the closing with TCP FIN+ACK, then OS/400 replies PSH+ACK.
Client is then able to get the latched QUIT response and terminates
gently.
3) On XP however, client answers to the closing packet by TCP RST+ACK;
as a side effect, it discards latched QUIT response and always returns
ECONNRESET upon read() :-(

I suppose XP does not like FIN+ACK+PSH, but who can be sure about what
happens in a closed system... I did not find anything on the web about
it.

Anyway, even if there is something weird at the system or socket level,
libcurl should not loop forever in those cases.

I tried to change ftp.c lines 447-448:

if (CURLE_OK != res)
  keepon = FALSE;

into:

if (CURLE_OK != res) {
  result = res;
  keepon = FALSE;
}

and it seems to do the job, but I'm not sure it does not break something
else.

I'll be glad to test your patch.

Cheers,
Patrick
Received on 2009-08-21