FileZilla Server Error: "421 No-transfer-time exceeded"

[mcjathan]

Greetings,

I have FileZilla Server version 0.9.41 installed on a Windows 7 Pro x64 machine. I've configured my router and firewall properly and ftptest.net indicates the router/firewall are indeed configured properly. I have a third-party FTP / Filesync program that uses the FileZilla server.

From the FileZilla server log, here is a common sequence of FTP commands executed by the third-party software as seen in the FileZilla server log:

> PASV
> 227 Entering Passive Mode (173,14,235,227,197,139)
> MLSD /R-Disk/folder1/folder2/TD Ameritrade/Distributions
> 150 Connection accepted
> 226 Transfer OK

I see this sequence (above) executed successfully literally thousands of times.

However, every now and then I see this:
> PASV
> 227 Entering Passive Mode (173,14,235,227,197,140)
> 421 No-transfer-time exceeded. Closing control connection.
> disconnected.

Either the third-party software is failing to send the MLSD command, or somehow the Filezilla Server is dropping the MLSD command, or my router / firewall is randomly blocking the MLSD command. I truly don't know where the problem is at this point.

Is there any known problem with router's and firewalls where a sequence of FTP command will get through OK hundreds and thousands of times but then a router or firewall will stop one out of a thousand?

Is there any known issue with FileZilla server that would cause what I'm seeing?

Regards,

Jeff

[boco]

Code: Select all

421 No-transfer-time exceeded. Closing control connection.

That line simply means the control connection is being closed because no transfer has been made for as long as you configured in your ''No transfer timeout'' in the FileZilla Server settings.

There are basically three different timeouts:
1. Login timeout - this one is for connections that never supply login data.
2. Connections timeout - If no activity is detected within that time the connection is terminated. Any action (including NOOP) will reset this counter.
3. No Transfer timeout - Only an actual transfer will reset that one. What your application does is not regarded as transfer and thus it disconnects you.

You could set the No Transfer timeout to zero, then the app will not be disconnected.

[mcjathan]

Thanks for that very fast response!

My "No Transfer timeout" is currently set to 600. I haven't changed it so I assume this is the default.

The app actually reconnects on its own (I assume after the timeout has been reached). The problem is that the app thinks it has sent an MLSD command (the Filezilla log shows no record of receiving the MLSD command) and in the confusion the app thinks FileZilla has responded that there are no files in the folder (an empty folder listing).

So, do you think changing the timeout from 600 to 0 is going to help?

[boco]

It will not solve the core problem (a possible bug in the app preventing it from reacting to FTP errors correctly), but it will prevent FileZilla Server closing the connection if the app didn't transfer anything recently (600 is only 10 minutes which is very low). The MLSD commands should properly reset the Connections timeout so that one can stay.

[mcjathan]

I guess I am seeing that there may be two core problems. The first one is what you mentioned -- the app is not reacting properly to FTP errors. This is definitely a problem and I'm currently working with the app author to get this corrected.

However, the second possible problem I'm seeing is the FTP / communication errors themselves. Here's what I don't understand. Basically what the app is trying to do is get multiple directory listings via the MLSD command. In my test case, there are more than 7700 directories. Everything is working flawlessly except for 3 to 5 directories (out of more than 7700). In other words, it's failing 0.06% of the time but working 99.94% of the time. Is that failure rate a normal, typical network failure rate that one would expect to see between an FTP client and server? Or, should I be looking to correct / fix something on the network between the FTP client and server?

FYI, I'm seeing two failure modes:

1) The app sends the MLSD command, but FileZilla Server never receives the MLSD command so FileZilla server times out (Error 421) and the App also sees the timeout.

2) The app sees this error at various points in the communication sequence:
winsock:Connect:error:(0x0000274c):A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Failed to connect the data port.
In this case, the FileZilla server also times out (421) and the App also sees the timeout.

So again, would I just expect to normally see errosr like this at a rate of 0.06%?

If it would be helpful, I can post the corresponding logs of the app and FileZilla Server.

[boco]

Is that failure rate a normal, typical network failure rate that one would expect to see between an FTP client and server?

With today's quality of firewalls and routers, unfortunately yes. Don't forget the net is a crowded place today and your connection may be routed through several countries before arriving. If the packets exceed the TTL (Time To Live) they are discarded and thus lost. If this happens too often your connection may break or stall. All you can to is checking the firewalls/routers under your control. Pray for the rest.

[mcjathan]

I need to back up a bit. This morning, the App author found an apparent problem in the FileZilla logs I sent him. It appears that Filezilla Server is timing out within 1 or 2 seconds even though these are my FileZilla timeout settings:

Connections timeout: 120
No Transfer timeout: 600
Login timeout: 60

Look at the two excerpts (below) from my FileZilla Server log:

EXAMPLE 1:
(000001) 10/4/2012 5:36:41 AM - freduser (166.70.54.154)> 150 Connection accepted
(000001) 10/4/2012 5:36:41 AM - freduser (166.70.54.154)> 226 Transfer OK
(000001) 10/4/2012 5:36:41 AM - freduser (166.70.54.154)> PASV
(000001) 10/4/2012 5:36:41 AM - freduser (166.70.54.154)> 227 Entering Passive Mode (173,14,235,227,197,172)
(000001) 10/4/2012 5:36:42 AM - freduser (166.70.54.154)> 421 No-transfer-time exceeded. Closing control connection.
(000001) 10/4/2012 5:36:42 AM - freduser (166.70.54.154)> disconnected.

EXAMPLE 2:
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> 150 Connection accepted
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> 226 Transfer OK
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> PASV
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> 227 Entering Passive Mode (173,14,235,227,197,153)
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> 421 No-transfer-time exceeded. Closing control connection.
(000003) 10/4/2012 5:55:41 AM - freduser (166.70.54.154)> disconnected.

Look at the time-stamps of the log entries. Notice that FileZilla is timing out within 1 second. Shouldn't FileZilla be waiting for 600 seconds in this case before timing out? Is this a bug?

Let me remind you that this problem seems to be very intermittent. Out of more that 7700 sequences of the App requesting folder listings from FileZilla Server, I'm seeing this problem about 5 times. So, the vast majority of the time FileZilla seems to be working properly and does NOT seem to be timing out prematurely.

I did notice a strange coincidence with these two examples. In both cases, the time-stamp ends on the 41 second mark. Just a coincidence?

Regards,

Jeff

[boco]

Shouldn't FileZilla be waiting for 600 seconds in this case before timing out? Is this a bug?

Nope. As I told you before, the No-Transfer timeout counter will only be reset by an actual transfer. What the app sends does not reset that counter.

The No-transfer counter is 600 seconds. So it will timeout after these 600 seconds except
1. you do a transfer on that connection, or
2. you close and re-establish the connection in the meantime.

So, from the timestamp of the 421 error, look exactly ten minutes back in the log. You should either find a login there or a transfer (last reset of the counter). The disconnection happening 1 second after the PASV is only coincidence, when the No-Transfer counter is zero, FileZilla will disconnect, no matter what else is happening at that time.

If you set No-Transfer timeout to 0, the app could be connected forever if it does at least some activity on the server (to reset the Connections timeout counter).

[mcjathan]

I confirmed that you are 100% correct. I went back 600 seconds (10 minutes) in the log and bingo!

I changed the No-Transfer timeout counter to zero and problem solved!

Thanks for patiently stepping me through this!

Best regards,

Jeff