IP Networking

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:
1. 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

2. 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).

3. 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.