ftp - lost

[worker201]

When attempting to connect to my Slackware ftp server, gFTP gives an error "no route to host". Just to be sure, I attempted to connect in from LeechFTP on a nearby Windows machine, and it's message was "Socket error: connection reset by peer". So I think this isolates the problem as a server one, and not a client one. It was working fine on Friday...

Here's what I have done to troubleshoot so far:
* run ps to see what's working - no entry for proftpd, but initd is working - I think this is correct behavior
* run ifconfig to see if the ip address was correct, and the connection is up - both are also correct - however, I notice that under TX packets, 5 overruns are listed - not sure what that means

What else can I do, besides roaming the building trying to find a tech support guy? The ftp server is really important to me and my work, and I need to have it working.

FTP machine details - Slackware 10.1, kernel 2.4.6, proftpd, ix86

[Void Main]

initd? Do you mean "inetd"? proftpd can be run as a standalone server or from inetd (xinetd in Fedora). If it's configured to run standalone then you should see a proftpd process running. If it's running from inetd then it should be configured to start proftpd in /etc/inetd.conf. Your proftpd.conf file should tell you which way it's configured and if you are having problems then you should see evidence of them in your system logs (see /var/log directory).

However, "no route to host" is a client error meaning you don't have a route in your routing table saying how to get to the IP address you need to get to, or the router signified by your default route doesn't have a route to get to that IP address.

[worker201]

God, I hope it is actually inetd. How embarassing. Anyway, proftpd is not set for standalone - it gets handled by in_e_td. So it's probably not that.

What would cause clients on the same network to suddenly not be able to connect? It's entirely possible that the network was completely reconfigured over the weekend, I guess.

[Void Main]

Well, I don't know without knowing the tcp/ip configuration of client and server and seeing the routing table (netstat -rn) on both client and server and knowing the physical makeup of the network.

[worker201]

Here's the netstat -rn results from both machines:

Code: Select all

Client - FC3 box
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.194.104.0   0.0.0.0         255.255.252.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         128.194.104.1   0.0.0.0         UG        0 0          0 eth0

Server - Slackware w/proftpd
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.194.104.0   0.0.0.0         255.255.252.0   U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.255.0.0     U         0 0          0 lo
0.0.0.0         128.194.104.1   0.0.0.0         UG        0 0          0 eth0


Of course, our network guy is nowhere to be found.

[Void Main]

Now, what is the tcp/ip configuration of both client and server (IP Address, Netmask, Gateway)?

[worker201]

Client:
IP: 128.194.106.137
Gateway: 128.194.104.1
Mask: 255.255.252.0

Server:
IP: 128.194.107.171
Gateway: 128.194.104.1
Mask: 255.255.252.0

[Void Main]

They are definitely on the same subnet so if they are both physically on the same side of the gateway then they should be able to talk to each other. They should not get a "no route to host" message. Can you ping the server from the client? Do you have any firewall software running on the server (iptables) or client (whatever Win uses)? Can you telnet/ssh to the server? If don't have any personal firewall stuff running and you can ping or ssh to the server then there is definitely an issue with the ftp configuration. If you can't ping or ssh to the server (assuming sshd is running) then it would appear to be a physical problem (bad patch cable, hub/switch, NIC, etc). A better test might be to ping both devices from a 3rd device on the same subnet.

[worker201]

[lholcombe@holcombe2 ~]$ ping 128.194.107.171
PING 128.194.107.171 (128.194.107.171) 56(84) bytes of data.
From 128.194.106.137 icmp_seq=1 Destination Host Unreachable

That's bad. Same results if I ping from server to client.

I don't have any clue how to telnet/ssh, but a regular telnet gives a 'no route to host' error.

There aren't any firewalls blocking ftp port traffic on either server or Linux client. If you recall, when I was setting this thing up for the first time, I couldn't get in from outside, because the overall university firewall wouldn't allow incoming traffic. That's why I was trying to find our local network guy, to see if they had cut off my ftp access. Honestly, you have done more work for this particular office than he has ever done, and he gets paid for this!

[worker201]

Well, I played around with the Slackware box to find out if it was really connected to the network. I tried to ping Yahoo, but it was unable to resolve www.yahoo.com. This leads me to think it cannot get to the DNS servers. Then I opened links and tried to visit a couple sites, with no luck (I verified that these sites were working with the adjacent Fedora machine).

So I figured this is proof that this computer is not actually on the network. Just to see if it helped, I attempted to take down and then put back up eth0. Well, 'ifconfig down eth0' and 'ifconfig up eth0' both do nothing, and after about a minute, I ctrl-C to stop them.


Christ, nevermind. I just looked, and the network cable had come undone from the wall. It's behind a bookshelf and unreachable, so I don't know which gremlins are responsible for this. But anyway, things work fine now.

I wish there was a Linux tool that would tell me to check that!

[Void Main]

As long as you don't tell us you are using that foot pedal that came with your server. :)

[worker201]

How hard would it be to change it so that if you bring up ifconfig, it prints a message like "If you are having troubles with your network, make sure all network devices are plugged in correctly. This may seem silly, but it happens more often than you think." right under all the information. This might be something that would be nice for home and beginner users.

And for intermediate users as well!


My feet have unplugged many things, but the cables in question here are not accessible by foot or hand.

[Void Main]

That message actually already exists in Fedora:

Code: Select all

# ifup eth0

Determining IP information for eth0... failed; no link present.  Check cable?


Of course that's only if you are using DHCP. You can bring the interface up without the cable plugged in and be just fine and there are times you might want to do this so it's hard to put a message in the case of a static address. I guess I have been doing this for so long some things are automatic for me. Not being able to ping by address things on local subnet usually means physical problem (cable unplugged or bad, bad switch or switch is off, etc) or bad driver.