ftp server won't accept connections

The 2.6.0-1 update works just fine so I don't think it would be the problem. And as you've noticed other ftp servers don't work either. I'd start figuring out what's going on by going back to wu-ftp as it should work okay. Then take a look at /etc/inetd.conf and make sure that ftp is enabled and that access is allowed by /etc/hosts.allow.

If those look okay, try running an ftp client on the system connecting to the system (ftp localhost). It sounds circular, but it's fine with Linux. If the client hangs, while it is up see if there is an ftpd process running.

If a local client can connect, but a remote can't, then the problem might be a routing problem. check by trying other access (telnet or rlogin) from the remote client. Also wouldn't hurt to take a look at "netstat -rn" on the server & the client to make sure the default route is correct.

Another possible problem would be that some router or firewall between the remote client and the server is blocking the FTP ports.

Okay look at those and let us know what you find out.

.and as always "Is DNS resolution working"?

OK, here's what I've checked out.  I'm back to running wu-ftpd-2.6.0-1.  In /etc/inetd.conf I have the ftp section enabled.  The entry is: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a.

/etc/hosts.allow and /etc/hosts.deny are both empty.  Also, I'm connecting to the machine via SSH so my path the remote machine is at least partially OK.

An attempt to connect to my server localally (ftp localhost) hangs with the message "Connected to localhost."

In answer to j2, I don't remember where to check to see if DNS resolution is set.

First of all, is it really "hung" or is it just waiting for a DNS resolution.

make sure that all IP's you will be connected from are present in /etc/hosts (or you have a proper DNS running).

like

192.168.0.100   gonzo.mupp.net

if the ip of the systme is 192.168.0.100 and the name is gonzo.mupp.net

also check so you have an entry for "localhost" in /etc/hosts

and also check that "files" is present as a parameter to hosts: in /etc/nsswitch.conf

When you used ftp localhost did you check to see if an ftpd is running while the ftp client is "hung"? (Hint, "ps -ef | grep ftpd | grep -v grep").

/etc hosts does contain an entry for localhost.  The main IP I connect from doesn't have a DNS name to resolve to, so I tried using another machine that did have a DNS entry.  I added an entry for the host in my /etc/hosts and still was not able to connect.  I've grep'ed the process list when trying to connect and don't see an instance of ftpd running.

Ha!, I'll bet something else is listening on the FTP ports and catching the connection. Since it's not an FTP server, the client just hangs waiting on a response.

Look in /etc/services and see if there's multiple definitions for ports 20/21. Also you should look at /etc/inetd.conf and see what's enabled.

Oh yeah, while the client is running you can find out what's on the FTP ports (as root) with: "lsof -i TCP:20 -i TCP21". That will returnfile names that are using the FTP ports.

In /etc/services I've got ftp-data on port 20/tcp, ftp on port 21/tcp and fsp on port 21/udp.

When I saw two entries for 21 I thought that must be it but then noticed that the fsp service is only udp.  I went ahead a commented it out though and tried connecting again but no luck.  Is there anything I need to restart after making a change to the services file (e.g. like kill -1 to inetd when changing inetd.conf)?

The only thing I have enabled in inetd.conf is ftp.

I ran lsof (which was a new command to me. Thanks!) and got info telling me the name of the service on that port was *:ftp (LISTEN).

aah.. It might be stalling waiting for an ident reply (which it wants after you installed the upgrade)

Run an identd server on the client.

I tried running identd on the client and still wasn't able to make a connection.

Curiosity.. when you tried proftpd, did you run it as standalone or as a service? and if you chose standaone (which is the better option) did you remember to comment the fpt line out of /etc/inetd.conf and then actually launch proftpd?

I also seem to recall this happening with proftpd if the IP of the client did not resolve back to a fqdn.

Did you use lsof while the "ftp localhost" was running? If you did (as root) it should have shown the client ftp process and some other lines for what else has the port open.

j2: When I tried proftpd I was running it as a service.  I'll try proftpd again and do it as a standalone.

jlevie: No, I didn't run lsof when a connection attempt was being made.  Here's the new info I got after doing so:

COMMAND ftp NAME localhost:3343->localhost:ftp (ESTABLISHED)

So it looks like the initial part of a connection is at least being made?

One more time... In one window as an ordinary user do "ftp localhost". In another window su to root and do "lsof -i TCP:20 -i TCP:20". There should be at two or more lines output. One for the ftp client (the ftp localhost) and one or more for what the client is talking to. It's tha latter That im interested in and only root can see them.

Ahhh, a bit of progress! bernardh's suggestion of changing the class line in ftpaccess now allows me to successfully login to the ftp server from localhost.  However, when I attempt to make a connection from a remote host I get to enter my username and password but every time it responds saying that the username/password were not accepted for login.

This occurs with or without the addition of -I 0 to the in.ftpd line.

So now I can log in from localhost but not remotely.

jlevie:  This time I ran lsof while ftp localhost was sitting at the password prompt.

I did receive two additional lines of output (that weren't there before I changed the ftpaccess):

Both are COMMAND in.ftpd and NAME localhost:ftp->localhost:3360 (ESTABLISHED) and the only difference is in the FD column "0u" vs. "1u"

to be able to allow real users (that is users you allow to access your ftp server, or users that have ids on the server), make sure that their user names does not appear on the file /etc/ftpusers. the user names on that file are actually the userids that are not allowed to access your ftp server.

Does your /etc/ftpaccess class line look like:

class   all   real,guest,anonymous  *

The user name I'm using to connect does not appear in /etc/ftpusers.

The line I'm using in /etc/ftpaccess is:

class lcl real,guest,anonymous 127.0.0.0:255.0.0.0

That restricts it to localhost, change 127.0.0... to "*".

Just needed to tweak the ftpaccess class suggestion you gave.

When I accepted the answer I thought it posted things backward from what I thought it would.

Anyway, jlevie stuck with this problem the longest but it was bernardh who did come up with the root solution to my problem.  Thanks to both of you.