TIDFTP sending short files goes to timeout

[Dany40]

Sorry, I think this one is much better log.

[daniel221]

A few things to check and try:

Increase timeouts on TIdFTP (ReadTimeout, ConnectTimeout, TransferTimeout). Small files can still hit timing issues if the data channel stalls.

Ensure you’re using True Passive mode (PASV) and that the FileZilla passive port range is fully forwarded through the NAT. Partial transfers like 1300 bytes are classic NAT/passive misconfig symptoms.

Try forcing single-connection transfers and disabling any keep-alive or compression options.

Test switching between Put(..., False, -1) and explicitly setting the transfer type and block size, or try Put with True (overwrite) to rule out resume logic.

As a diagnostic step, test with Active mode or another FTP server to confirm it’s not an Indy/FileZilla interaction bug.

Indy’s FTP component is generally stable, so when only a few files fail consistently, NAT + passive ports + timeout tuning is usually the root cause.

[Dany40]

Hello Remi, did you see something on the logs, that can be a clue?

[Dany40]

Thank you Daniel;

Increase timeouts on TIdFTP (ReadTimeout, ConnectTimeout, TransferTimeout). Small files can still hit timing issues if the data channel stalls.

Ensure you’re using True Passive mode (PASV) and that the FileZilla passive port range is fully forwarded through the NAT. Partial transfers like 1300 bytes are classic NAT/passive misconfig symptoms.

Try forcing single-connection transfers and disabling any keep-alive or compression options.

Since 2023, I send more than 80.000 files every day to those FileZilla servers, I don't think I have missed some configuration.

Test switching between Put(..., False, -1) and explicitly setting the transfer type and block size, or try Put with True (overwrite) to rule out resume logic.

Ok, good idea; I tried now but same error.

As a diagnostic step, test with Active mode or another FTP server to confirm it’s not an Indy/FileZilla interaction bug.

I didn't tried that, but I already tried to send this file using other FTP clients and they are working always fine.

Indy’s FTP component is generally stable, so when only a few files fail consistently, NAT + passive ports + timeout tuning is usually the root cause.

I am sure of that, I use DataSnap since 2008 (Indy is inside it) and never a problem. Also I use TIDFTP for years, never a problem. I think the problem is the server environment, but the fact that other clients can send that file is a point to considere.

[rlebeau]

Hello Remi, did you see something on the logs, that can be a clue?

I haven't had time to look at the Wireshark capture yet.

[Dany40]

Hello; Let me add here a new set of log files in where we can see what happen when a FileZilla client send the same file to the same FileSilla server, so we can compare.

[rlebeau]

Thank you; here I am sending you the WhireShark log.

Why did you export it as a CSV file and not as a PCAP file? The CSV file is completely useless as it only shows TCP packet headers but not any of the actual TCP payload data.  So I can't see any of the FTP traffic.

Sorry, I think this one is much better log.

Thank you, yes. For future reference, forget the CSV files, and also you don't need both PCAP and PCAPNG files, just one will suffice (preferably PCAPNG).

In any case, looking at this 2nd log, the file transfer itself progressed fine (0x00 bytes and all), but at the end of the transfer when TIdFTP closed the data transfer connection, there was no FIN packet from TIdFTP to the server (well, the log shows the packet, but says "previous segment not captured"!). So, if that FIN did not actually get transmitted to the server, that would mean the server did not know the transfer was finished, which would account for the timeout when TIdFTP then tried to read the server's final response for the transfer, since the data connection was still open.

Hello; Let me add here a new set of log files in where we can see what happen when a FileZilla client send the same file to the same FileSilla server, so we can compare.

That 3rd log is encrypted with TLS, so the FTP traffic is not viewable, and difficult to match up the data transfers with the data commands. The TIdFTP client did not use TLS, but the FileZilla client did. At the very least, you should be able to export a plain-text command log from the FileZilla client alongside a Wireshark capture, if you don't want to disable TLS.

[Dany40]

In any case, looking at this 2nd log, the file transfer itself progressed fine (0x00 bytes and all), but at the end of the transfer when TIdFTP closed the data transfer connection, there was no FIN packet from TIdFTP to the server (well, the log shows the packet, but says "previous segment not captured"!). So, if that FIN did not actually get transmitted to the server, that would mean the server did not know the transfer was finished, which would account for the timeout when TIdFTP then tried to read the server's final response for the transfer, since the data connection was still open.

Ok, but why is that; and what do I have to do on that case?. I am doing for that file is exactly the same I do for all the other files I send all the time to that server.

[rlebeau]

Ok, but why is that; and what do I have to do on that case?

I can't answer that. It is difficult to tell from your captures whether the FIN is actually being transmitted or not. The FIN is the signal that a transfer has finished and was not aborted. Indy merely shuts down and closes the data socket gracefully, but it is the OS's responsibility to actually transmit the FIN. Maybe something in your environment is preventing that? Who knows.

Can you provide a capture from the server-side when the problem happens? I would like to see a Wireshark capture of the client and the server for a single failed file, as well as a log of the FTP commands.

[Dany40]

Can you provide a capture from the server-side when the problem happens?  I would like to see a Wireshark capture of the client and the server for a single failed file, as well as a log of the FTP commands.

Hi Remi, I can provide you full access to this test machine, please let me know if you want that.