Wait to send 226 until data transfer complete

[Nathan Reynolds]

I am trying to debug a situation. My FTP client initiates a download of a file using EPSV. FileZilla FTP Server writes all of the file data into the data socket buffer. FileZilla FTP Server then sends reply code 226 (closing data connection. Requested file action successful) on the command socket.

Using Wireshark, I can see that the 226 packet is sent on the network before the entire file is sent. At some point during the file transfer, a packet fails to be ACKed by the client. The server OS retransmits the packet 4 more times and then gives up. This problem is not FileZilla's issue.

The problem is that FileZilla FTP Server will send 226 before the data transfer is complete. Instead, FileZilla should wait to see if there are any problems with the data transfer and only send 226 when it has fully finished.

[Tim Kosse]

Your client must be prepared to receive the 226 before the FIN on the data connection, there is no ordering of packets between two different TCP connections.

When FileZilla Server sends the 226, the transfer has already finished successfully from its point of view.

Unless you artificially delay every transfer for 4 minutes (the maximum allowed RTO of TCP) there'll always be cases where a client sees the 226 before receiving, or failing to receive, the FIN on the data connection.

Your client should only recognize the transfer as successful if it has both received a FIN on the data connection as well as the 2yz to the transfer command. If the connection is closed by RST or a timeout or if a non-2yz reply code is being received, then the transfer has not been successful.

[Nathan Reynolds]

My client ignores the 226 until the data has been fully received. It properly flags a problem if it doesn't receive the FIN or 2yz. This is how I knew there was a problem.

The problem is that FileZilla Server doesn't wait for the FIN to be sent. It doesn't complain about the error on the data connection in the logs. It simply believes everything went smoothly with the download when it did not.

I am asking for FileZilla Server to say something in its log about the network error. This will make debugging this kind of problem easier (i.e. improve diagnosibility). Because FileZilla's logs said everything was fine, I figured my client was doing something wrong and wasted a lot of time looking at the client. It wasn't until I used Wireshark on the server to see the networking errors and then figured out that the transfer error has nothing to do with FileZilla or my client.

[Tim Kosse]

When FileZilla sends the 226 on the control connection, it has already handed off all data to the TCP stack and initiated a graceful socket shutdown. From that point on there simply is no way to get any feedback from the network anymore.