Compatibility between FileZilla server and TotalCommander as client

[Andrew]

There is a problem that present for a long time - FTP client built in TotalCommander have bad compatibility with current FileZilla server - it may sometimes show empty folders that are full of files or drop filetransfer after random file.

It loks like appeared from some FileZilla server update near 2 years ago.
I'm not sure what is source of a problem, FileZilla server log not helpful in this case too. Also I'm not even sure that problem is on TotalCommander side or FileZilla server side (but official FileZilla client have no problems with same server). What I know - it not depends on connection way (SSL or normal, passive or not), but depends on client side - there is more prolems when client is an old slow PC and/or slow internet connection. From server side - there is more chance for interrupted transfer, if try to download a folder with a lot of small files (real example - saved webpages with all their resources/images/scripts)

Closing ticket as it must be a client-side issue, there is nothing in the server log that matches the described symptoms.

[Andrew]

example log

[Andrew]

On error there are such strings in log:
(000001)10.02.2018 9:31:12 - amigos (77.123.238.103)> 421 Could not create socket.

[Tim Kosse]

There are three main reasons for the 421 in the reply to the PASV command:

• The server has a too narrow passive mode port range configured
• There is a general exhaustion of ports on the server system
• Some firewall is interfering with creating the listen socket

Apart from this there are two oddities:

The client always sends _both_ PASV and PORT, first switching to passive mode only to immediately switch back to active mode. That's just pointless.

The client uses the ABOR command. The semantics of the ABOR command are ill-defined by the FTP specifications, it should not be used by modern clients. Modern clients if they wish to abort should simply close the connection.

Explanation for the ABOR issue: In FTP there must be exactly one reply for every command. The exception is the ABOR command which aborts any previous command, skipping its reply. The problem is that ABOR can be issued after the reply to the prior command has already been sent but not yet received by the client. The client thus does not know whether there will be one or two replies to receive after sending ABOR, screwing up FTP's command-reply sequence if it takes the wrong guess. The only way to prevent this is to stay idle for a long time to ensure there's no outstanding reply, but even that is no guarantee as it may take minutes for the reply to reach the client, e.g. under very high system load. Thus ABOR should be avoided at all costs.

[Tim Kosse]

Another thing: The client is connected through a public IP address, but uses a PORT command with an unroutable private IP address. Most likely the client sits behind a NAT router and needs to be configured correctly so that it knows its public IP address.