FTP connection is slow --

[BalajiJV]

Hi,

We have a server installed with RHEL3. Using the server as FTP server. Whenever trying to connect this (FTP) from any other server, it is responding slowly (taking 30 sec approx.). How to reduce this delay ? any solution from your side?

[Steven E. Protter]

Shalom,

Take a quick look at /etc/hosts

See that the system has a line in it to resolve its own host name to its public IP address.

Adding this deals with a common problem, which is slow DNS response.

You may need to look at /etc/nsswitch.conf to insure that files is part of host resolution, ahead of DNS.

You can test this little theory by seeing if the ftp connection works faster if you use the systems numeric IP address as opposed to its hostname.

If the actual file transfer itself is slow, check the systems network duplex with mii-tool and/or ethtool.

SEP

[Matti_Kurkela]

FTP server software will often try to send an identd query to the client system by default. 30 seconds sounds like a common time-out value for an identd query.

This used to be somewhat useful in the past, but in modern networks, the identd service is usually disabled (or does not exist at all, like in Windows systems) and/or traffic to the identd port (113/TCP) is blocked in most firewalls.

There are two ways for a firewall to block a connection:
A) drop the connection, i.e. simply pretend the connection attempt did not exist. In the firewall rules, this is usually known as the DROP rule.
B) fake a response from the target system, saying essentially "this service is not available, don't bother trying." In the firewall rules, this is often known as the REJECT rule.

If there is no firewall, but the target system does not have the service requested, the target system would send a response identical to the type B.

When the FTP server sends an identd query, it expects to receive either a valid identd answer or a type B rejection.
If there is a firewall with a type A block for identd queries, the FTP server cannot detect it in any way: it is indistinguishable from a really slow connection. So the server must wait until the identd query times out.

But as the response to the identd query is optional, the connection can then proceed as normal.

Things to do at the FTP server side:
- If you wish to use the identd queries, make sure the FTP server's own iptables firewall does not block the identd responses.
- If you don't care about the identd queries, switch the identd query function off in the FTP server configuration.

Things to do for firewall administrators:
- Please don't use DROP rules for the identd service (113/TCP). Use the REJECT rules instead. If you're worried about someone using the rejection response as a component for DoS attacks, set up a firewall rule that limits the maximum number of identd connections, and uses the DROP rule only if the number of connections is excessive.

See also:
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

MK

[BalajiJV]

Entry made in /etc/hosts and also checked earlier with nsswitch.conf entries. I am trying with numeric ip instead of host. I think this would not be worried with nsswitch.conf file.

One more issue is: A scritp is written to connect ftp and it is working fine when it is executed manually. But when it is scheduled the script is firing but the log says "login failed"

[Michael Steele_2]

Have you check the speed and duplex of all nodes inbetween?

For your linux box use 'ethtool'.

ethtool eth0

[Steven Schweda]

> Entry made in /etc/hosts and also checked
> earlier with nsswitch.conf entries.

Which entry on which system? Checked what
how? As usual, showing actual commands with
their actual output can be more helpful than
vague descriptions and interpretations.
Saying exactly what you did, and where you
did it, and what happened when you did it
may be more helpful than saying what you
think it all means.

The usual slow-connection problem occurs when
the server can't look up the client's IP
address (to get the client's name). The test
involves (on the server):

nslookup client_IP_address


> A scritp is written [...]

If my psychic powers were stronger, then I
might be able to tell you something about
your secret script.

[BalajiJV]

Yes I checked it

$ sudo /usr/sbin/ethtool eth2
Password:
Settings for eth2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes

[Michael Steele_2]

You only checked you NIC. Traceroute the connection and verify the speed and duplex for all hops in between, including switches / ports.

[BalajiJV]

# traceroute linuxftp
traceroute to linuxftp (172.17.4.100), 30 hops max, 40 byte packets
1 linuxftp (172.17.4.100) 0.161 ms 0.125 ms 0.135 ms

[Michael Steele_2]

Sigh.

Switches, like bridges, I don't think are going to show up in traceroutes as your default router is.

Please contact the network admin for a topology.

Please follow you network cables and ID the switch and port that you are plugged into.

[Steven Schweda]

> [...] Whenever trying to connect this (FTP)
> from any other server, it is responding
> slowly (taking 30 sec approx.). [...]

Are data transfers slow, or is the only
problem a delay when first connecting?

If the only problem is a delay when first
connecting, then the problem is not likely
to be anything in the network hardware.

> The usual slow-connection problem occurs when
> the server can't look up the client's IP
> address (to get the client's name). The test
> involves (on the server):
>
> nslookup client_IP_address

I'm still wondering how that works.

[BalajiJV]

data transfer is fine without any delay. Only the connection initiation takes time.

[Steven Schweda]

> Only the connection initiation takes time.

Ok. That means that you can safely ignore
all the noise about network hardware
problems.


> I'm still wondering how that works.

Still true.