TotalCommander and FileZilla server compatibility

[b1Ack]

There is a problem that present for a long time - TC 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 TC 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)

Christian, if you will have some time - can you please review this issue ? If needed - I can make some test area on my own filezilla-based FTP server.

I already posted a ticket to FileZilla tem: https://trac.filezilla-project.org/ticket/11512

[b1Ack]

FileZilla team says that is client-side issues, details are pointed on ticket comments.
In this case - server have dedicated IP, client is behind NAT. But I can see the same issues even if directly connect client to server via LAN wire within 192.168.0.* IP range for both of them.

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.

comment:3

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.

[ghisler(Author)]

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.

This can happen when the server reports the private IP address in reply to the PASV command. TC _should_ use the public IP address in this case, but it seems to fail in your case. That's why TC then tries PORT command. Can you try to disable passive mode?

[b1Ack]

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.

This can happen when the server reports the private IP address in reply to the PASV command. TC _should_ use the public IP address in this case, but it seems to fail in your case. That's why TC then tries PORT command. Can you try to disable passive mode?

When this problem happens I try both passive and active modes, and FTPS on/off. Usually Passive + FTP (usual, without SSL) is more stable. But not always. And this can happen even via LAN directly by cable. More chance to get interrupted transfer is for old/slow PCs and/or for multithreaded transfer (all within limitations set on server).

[gdpr deleted 6]

This can happen when the server reports the private IP address in reply to the PASV command. TC _should_ use the public IP address in this case, but it seems to fail in your case. That's why TC then tries PORT command. Can you try to disable passive mode?

No, here in this case the server does not transmit its private IP address. It correctly announces its public IP address 109.254.37.109, as can be seen in the server log file which b1ack attached to his Filezilla ticket (direct link to log file).

Whatever is going on there does not seem to be caused by a misbehavior of the server.

When looking closer at the log, it is all a bit weird (i assume the server log provided by b1ack is only about sessions with TC's built-in FTP client).

The client requests passive mode, passive connection is established and then the client just changes its mind, switching to active mode (as also noted in the response by the FileZilla team):

Code: Select all

> PASV
> 227 Entering Passive Mode (109,254,37,109,224,44)
> PORT 192,168,0,102,195,194

Some other times, for reasons not visible in the server log, establishing the passive connection fails altogether (followed again by a switch to active mode):

Code: Select all

> PASV
> 421 Could not create socket.
> PORT 192,168,0,102,195,198

If you ask me, there is something funky happening on the client side. To get a better picture of what is going on , it would be necessary to see a client-side log (from TC)...

[ghisler(Author)]

What happens is that TC tries to connect to the reported IP address, 109.254.37.109 and port 57388 (224*256+44), but apparently the connection fails. Then TC tries to switch to active (PORT) mode. But this fails too because 192.168.0.102 is an unroutable internal IP address.

Could you try connecting with FileZilla client to that server? How does the log look like then?

[b1Ack]

Of cource I tried with LAN adresses too. And sometimes it was failed. When have opportunity to clearly reproduce this error and make one more log for you - will post it here.