FTP Slow to Connect At First

ftp

I have been scratching my head over this one for months, and cannot make any sense of it. It is happening not just to me, but others confirm the same thing happens to them. There mat be some logs I need to check, or tools I need to use to trace what is happening, but I really don't know where to direct that effort. This is the problem:

At my office, connecting to a remote FTP site takes 20-30 seconds to connect. Once connected, the speed is great. If the FTP client times out, then it takes another 20-30 seconds to reconnect.

Once connected to a server, I can open additional FTP connections, and they connect instantly – there is no delay. That is, until the client times out through non-use and needs to reconnect again.

If I connect using my client, it takes 20-30 seconds. I can then close the client down completely, and open a new instance. That connects immediately. If I wait a few minutes before attempting to connect, then I get that slow initial connect again.

This does not happen at home, with my same laptop. The office connection is a Virgin cable Superhub V1, running DHCP and being provided with a fixed public IP. I have a mail and file server on a DMZ on the inside of the network, but traffic does not pass through that server.

At home I use Virgin cable with the Superhub V2 in passthro/routher mode. An SME Server sits on that, and all traffic passes through that server, which acts as firewall, router, internal DHCP etc.

Other workers have other home Internet connections, different OSes and clients, and see the same thing (e.g. OS-X with its built-in client).

What could be causing this? Are there logs on the remote servers I am FTPing to that would tell me what could be happening? Can the protocol be monitored while connecting to see what could be the problem?

Sorry if this is the wrong place to ask this. It kind of crosses right over networks, servers and development tools.

Edit: ssh connections to the same servers is instant – never a delay there.

Looking at the messages log, this appears after some time of FTP inactivity, indicating it is probably my client that closes the connection:

proftpd: server-ip (my-ip[my-ip]) - Client session idle timeout, disconnected
proftpd: server-ip (my-ip[my-ip]) - FTP session closed.

Then this appears in the log when connection to FTP again, immediately after the 20 second delay and the client indicating that it has connected:

xinetd START: ftp pid=15055 from=::ffff:my-ip
www proftpd[15055]: server-ip (my-ip[my-ip]) - mod_tls/2.6: no TLSRSACertificateFile, TLSDSACertificateFile, TLSECCertificateFile or TLSPKCS12File configured; unable to handle SSL/TLS connections
www proftpd: server-ip (my-ip[my-ip]) - FTP session opened.

(IP addresses replaced with my-ip and server-ip)

Best Answer

The most frequent causes for login delays with proftpd are:

Reverse DNS resolution of client IP (disabled via UseReverseDNS off)
RFC1918 lookups (disabled via IdentLookup off)
Timing delays added via mod_delay (disabled via DelayEngine off)

Hopefully one of these tweaks will help!

Related Solutions

Ftp – Why does FTP passive mode require a port range as opposed to only one port

a clear and technical explanation with regards to the multiple concurrent FTP sessions issue when locking the data port to only one port is what I am most interested in knowing in depth. When can it work, when will it not work, why it may not be recommended, etc.

This will be a wild guess, as I haven't tested it, you should try it for yourself and see if there are some other problems I might have missed.

I suppose you could limit the passive port range to one single port. In fact you can see in this question that small port ranges are used in practice. Theoretically, to support multiple concurrent connections you only need the 4 values: local IP, local port, remote IP, remote port to be unique. This is how you discern between different connections.

If you lock down the port on your server to one single value, then the only variable left is the port used by the client. This is not a problem, as long as the client has a large enough pool of free ephemeral ports to choose from. Unless it's doing some heavy NAT, you don't have to worry about this. Now, be warned this will be purely theoretical stuff: if you used multiple ports on your server, you could multiply the number of hypothetical concurrent connections by enabling number of ports in range connections per one port client-side. But it won't happen in practice, as I doubt there's any implementation of an FTP client that would support this (because it doesn't make much sense). Plus if the client has to share his ephemeral ports in this way and can't just open a new one, then he has much more severe problems to deal with. So, from this perspective you should be totally safe using a single port.

Let's think why a single port may not be sufficient.

First of all, I could come up with a situation where a really buggy FTP server implementation uses solely the local port number as a way to identify the client data transfer. Once again, I don't think any decent FTPd would do that.

The real problem (yes, you can disregard all above as a major digression ;-)) is that passive port range is in a non-privileged range.

This means that your selected port number is not reserved per se, and in fact any user process (doesn't need root privileges) can grab it before your FTP server does. If you have an abundant pool of ports to select from, you just grab a random free one. If you're bound to use the only one and it's already used, you won't be able to handle the transfers properly.

Sorry, if the answer seems a bit too speculative. To be honest, I tried hard to find a reason why you shouldn't use a single port and, apart from the last bit, I couldn't think of any hard evidence against it. Nevertheless, an interesting and challenging question you pose.

Debian – Slow FTP Issue when there is no DNS server

I not certain if this will help, but if you have no DNS server you should populate the /etc/hosts file on each host.

Here is an example format:

198.51.100.1    host1.example.com host1
198.51.100.2    host2.example.com host2
198.51.100.3    host3.example.com host3

Best Answer

Related Solutions

Ftp – Why does FTP passive mode require a port range as opposed to only one port

Debian – Slow FTP Issue when there is no DNS server

Related Topic