We have moved our DNS and DHCP to Windows 2000 from BIND. Our FTP Server is running Solaris 2.6, users who receive an i.p. address from win2k DHCP receives a connection failed error when trying to FTP and users who have static i.p. address can FTP with no problems. Can anyone shed light as to why this would happen?
From one of the system that cannot ftp, try to ping the ftp server by ip address. Does that work? If so, try to ping the ftp server by name. Does that work?
I can ping by name and I can use nslookup to find the server. It appears that if Windows 2000 DHCP issued out the i.p. our Unix FTP server refuses the connection
What ftp daemon are you running? Some of them try a reverse dns lookup to get the hostname. From the server can you do a nslookup on the ip address of the client? When the clients switched to dhcp did they wind up on a different subnet? Could you be running tcp wrappers or something like that on the server? Is there a firewall between the server and the client? This could be a firewall issue.
We are running inetd.conf (1m) 1.2.7 SRV 4.0.1.5
Yes I can do a nslookup back to the client from the FTP Server
I not sure if we are running TCP wrapper or not but from what I can tell we are probably not, this is all I see when I check inetd.conf file: ftp stream tcp nowait root /usr/bin/in.ftpd
The dhcp client are on the same subnet as the Unix box
I am also having problem telneting into that Unix box as well.
Check your /etc/hosts.allow and /etc/hosts.deny - you are probably being blocked because of the change in IP addresses. Add the new subnet to /etc/hosts.allow and it should work.
The subnet range was in the host.allow, typed in the ip address of the client that was failing. Still no response, it connects to the port 21 and receives a message that "host lost connection". There is no deny.allow file.
When looking at DHCP, if I grab an i.p. address out of the range of ip address that has not been assigned by DHCP and hard code it into my workstation I can connect with no problem. But if I set DHCP up to send the i.p. by reserving the mac address it fails. Is there some type configuration in Unix that can distiquish if an I.P. address was sent via DHCP. As you can tell I am not a Unix expert just a beginner. But I appreciate all the response you are giving.
The unix host should not care whether or not dhcp was used to assign the client's ip address. Most unix systems can be a dhcp server. My pc got its ip address via dhcp and I can ftp to our ftp server just fine.
More stuff than ip address comes from a dhcp server. Netmask, default gateway, and even routing table entries can be set. Could these be wrong? Is it only ftp? Can you telnet? Can you ftp to any other boxes?
The configuration for the subnet mask, default gateway, DNS, WINS is the right IP address in DHCP. I have not done anything with routing table we are on a flat network the only router we have goes out to the Internet. I cannot ftp or telnet the Unix box, although I can telnet and ftp other Unix box in our network. It seems like a configuration problem within this one box. I just do not no what it is.
Sorry, for getting back so late but I had another project that I needed to finish. However, we are still having the problem; the temporary fix is to hard code all clients that need to ftp or telnet to the Unix box with a static i.p. address.
I was checking back through old posts I had responded to and came across yours. Did you ever get this working?
Some other thoughts:
- INETD
You could change your /etc/hosts.allow file to have all ftp accepted by putting this into the file:
in.ftpd: ALL
You wrote:
this is all I see when I check inetd.conf file:
ftp stream tcp nowait root /usr/bin/in.ftpd
The entry should have one more piece:
ftp stream tcp nowait root /usr/bin/in.ftpd in.ftpd
Insure no spaces at the begining of the line or at the end (actual case in SunSolve mentioned this error)
Insure that /etc/inet/inetd.conf is linked from /etc/inetd.conf.
# ls -l /etc/inetd.conf
lrwxrwxrwx 1 root root 17 May 7 2001 /etc/inetd.conf -> ./inet/inetd.conf
-
RESOLV.CONF
Did you check your /etc/resolv.conf to point to the correct nameserver? Are you running bind on the ftp server? If so, was it stopped and restarted (Solaris will cache entries and ignore changes in DNS - caching only servers are needed on the server if you use any round robin). -
REBOOT
Last resort - reboot and see if the problem goes away. Could have cached other info which is interfering (arp table, network routes,...)
We have tried everything you listed, except for reboot and nothing helps. We will reboot over the weekend and I will keep you posted.
Thank you for your response to this problem. The problem has been resolved. It appears that our unix server had a restrict set that did not allow a workstation to connect via FTP Or Telnet if it did not have the domain name associated with it. When workstations were dynamically registering itself with DNS it did not registered the FQDN, just the host name.