1

Basic question: if I get a decent ping between hops in a traceroute reading, BUT I'm unable to connect to the host via FTP, what does that imply?

By connecting via FTP, I simply mean using FileZilla and the error is "Connection timed out". However, my traceroute reading to that IP doesn't indicate a lag issue.

I've removed the IP addresses below, but this is what the reading looks like:

traceroute to 207.xxx.xxx.xx, 30 hops max, 40 byte packets
 1   <server>  0.788 ms  1.135 ms  1.135                                                                              ms
 2  <server>  0.677 ms  0.688 ms  0.679 ms
 3   <server>  4.526 ms  4.500 ms  4.500 m                                                                             s
 4   <server>  1.502 ms  1.507 ms  1.502 ms
 5   <server>  4.771 ms ae1.ar2.ord1.us.nla                                                                             yer.net (69.31.111.146)  4.761 ms  4.734 ms
 6   <server>  1.456 ms !N  1.300 ms

Any ideas or suggestions? Thanks!

Ray
  • 147
  • 1
  • 7
  • Note that we were able to connect to the FTP port on this server...just not as of today. Apart from a possible port blocking, would there be any other reasons? – Ray Aug 12 '11 at 18:23
  • Try ruling out Filezilla by connecting via a command line. You might also try connecting from a different host and/or network. Also, verifiy that the FTP service is running on the target host. Just because it should be running doesn't mean that it is running. – joeqwerty Aug 12 '11 at 18:26

4 Answers4

5

Is there an ftp server listening on 207.x.x.x. ? Is there a a firewall and is it configured to allow connections to the ftp server?

user9517
  • 115,471
  • 20
  • 215
  • 297
  • I just edited my question. Yes, there should be an FTP service on that server. – Ray Aug 12 '11 at 18:24
  • 2
    @Ray: `Should` ? You really need to check with the server admin and while you're at it ask them if anything has changed. – user9517 Aug 12 '11 at 18:27
3

It means that the host is accessible on the internet, but is not responding to attempts to connect to FTP.

This will be due to either a lack of a running FTP service, a firewall blocking the port (more likely, since you got a timeout instead of a refusal), or both.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Just changed the question, but since we were able to FTP to it before, there should be a service on it. – Ray Aug 12 '11 at 18:24
  • @Ray Verify that the service is up, and that no firewall changes have been made - if it's not a device that's under your control, you should probably be harassing whoever controls and has access to it. – Shane Madden Aug 12 '11 at 18:27
2

As Shane Madden and Iain say, connection attempts on TCP port 21 (FTP) aren't getting through. You might try tracing the route using TCP to find out where the connection is getting dropped, e.g.

nmap -Pn --traceroute -p 21 207.xxx.xxx.xx

or 

tcptraceroute 207.xxx.xxx.xx 21
user9517
  • 115,471
  • 20
  • 215
  • 297
Gerald Combs
  • 6,441
  • 25
  • 35
0

First a quick aside, to discuss testing with the right tool.

ICMP tools have long been the conventional method of testing connectivity, but they are not always good tests. As you found out, you can happily reach your server via ICMP but not using FTP (running on top of TCP/IP). Would testing the latency of web site by sending ICMP traffic at the server that is hosting it yield meaningful and useful results? Probably not. A tool like httping or mtr would be a much better choice in this case.

ISC has a nice little article about this issue here: Ping is Bad (Sometimes)

So for a lot of reasons, PING is simply a bad test in many situations. Either it shows things are down when they're up, or if you are using it as a measure of performance, it's not measuring what you think it's measuring.

What should people do? Well, first, test hosts for up/down status on transports that they will receive and reply with. So a webserver should probably be tested using tcp/80, not icmp echo and echo reply. Similarly, RTT (Round Trip Time) performance of networks should be measured using the protocols that we actually wish to measure. Protocols such as tcp/80 (http), tcp/443 (https), or tcp/445 (Server message block (SMB) over IP (Microsoft-DS)).

@Gerald Combs' suggestion is excellent. Try using a TCP-based method of checking for connectivity.

You can verify that TCP/21 is open and receiving connections by using telnet:

telnet 207.xxx.xxx.xx 21

If you can successfully connect then you can confirm that you can reach the FTP server (i.e., there are no firewalls blocking your connection) and the FTP server is running. If this is the case then your problem lies somewhere in the Application Layer. As others have pointed the problem is more likely that there is either no FTP server listening and/or a firewall is blocking the connection.