Slow FTP with BSD 5.0

Started by
13 comments, last by Monder 20 years, 8 months ago
I''ve just set up a FreeBSD 5.0 box up on my network. I''ve enabled anonymous ftp on it and it''s working but there''s one problem. It takes about two minutes for the server to respond to the client but after it does everything runs at a decent speed. Does anyone know what may be causing this long delay between the client first trying to connect and the server responding?
Advertisement
quote:Original post by Monder
I''ve just set up a FreeBSD 5.0 box up on my network. I''ve enabled anonymous ftp on it and it''s working but there''s one problem. It takes about two minutes for the server to respond to the client but after it does everything runs at a decent speed. Does anyone know what may be causing this long delay between the client first trying to connect and the server responding?


My guess is that the server is trying to do a reverse DNS lookup (in order to write a name to the log) and that the client is not part of a domain, so the server has to wait for the request to time out.


Hope this helps.
You''re probably right, thanks. I''ll go RTFM to find out how to disable it.
Actually, I think TCP Wrappers does that. Been a while since I dove into the exacts. Usually the best thing to do without disabling logging and other good to have functionality, is to just pre-populate your hosts file for your network.

Assuming you''re running a 192.168.0.0/24 network you can do a simple python or perl script to generate the hosts file:

#!/usr/bin/python

for i in range(0,256):
print "192.168.0.%d n0-i" % (i)

Do a test run to verify it looks good (no errors): ''python <scriptname>''

If it looks good, back up your hosts file and just add the python script output to the end of hosts

cp /etc/hosts /etc/hosts.org
python <scriptname> >> /etc/hosts


If you''ve only got a few machines you can swing back and change the hostname to something more in line with your network. If you got a lot of hosts, you should set up a DNS server.

This way all logging and reverse-lookups do resolve and to something you can identify. (n0-254 is 192.168.0.254 for example).

Interim
Well in the end I did just put my other computer''s (it''s a rather small network ) ip in the host file with a host name. However it still takes ages for the server to respons. Could inetd be causing it?
Oh and what''s a 192.168.0.0/24 network? I''m sure it''s something to do with subnetting but I can''t quite remember.
I was guessing your network was the standard private address space (192.168.0.0/24 = 192.168.0.0 255.255.255.0). Most people use 192.168.0.0 or 192.168.1.0.

Hrms, what you did with your host file should have worked. You sure you got the syntax right?

On your FreeBSD machine, make sure you can ping your other machine by hostname?
I''m sure it''s right, because I can ping my other machine and when I connect to the FTP server my machine shows up in the logs with the correct hostname.

And yeah I am running a 192.168.0.0/24 network in that case I suppose the 24 means 24 subnet mask bits?
Sorry, yes. /24 is CIDR (Classless Inter-Domain Routing) notation. /24 = 24 bits.

I wonder if its your FTP client. Try adding the server to your host file on your FTP client machine.

Then, as another quick test, try to connect to your IP of your FTP server from the server with an FTP program. See if you get the same slow connection.

What you describe is classic FTP and other internet service issues on Unix without DNS setup thoroughly, but usually what I described will rectify that immediately.

Does FreeBSD 5.0 have xinetd by chance? I got some defaults of 5.1, but no xinetd, there are some tweaks you can do there for the log_success to speed up connections.

Int.
Hmm well when I connect to the ftp server using an ftp program on the server itself I still experience the same delay . I don''t have xinetd on this box, though I could install it through the ports system. Seeing as this box is just a little server I''ve set up I don''t really need inetd, so I''ll set it up so the FTP server just runs from bootup and see if I still get the delay.

This topic is closed to new replies.

Advertisement