I have a problem where on one unix machine I can telnet all IP addresses in the host file with no connection problem and another machine has recently started to have trouble connecting with the same host IP's on just some IP addresses where it had no trouble before. Have any ideas??

maybe that server is installed with tcp wrapper.

In TCP wrapper you can specify which IP address is allowed to connect. Maybe the other host or PC using DHCP and the IP changed so previously he could get in but now couldn't.

How would I check to see if tcp wrapper has been put in place or activated since we just recently started having this problem?

Search your server for a file called inetd.sec

find / -name inetd.sec -print

if you do find it back it up first before making any changes. You can edit this file on the fly there is no need for reboot or restarting any processes.

The other possibility is that the host trying to connect to the server does not have a route. to check you can do a netstat -rn

good luck

TCP wrappers uses the /etc/hosts.deny file to control access. It will produce something in the system log when a connection was blocked.

It doesn't just go activate itself so I'd bet more on the random DHCP fluff theory.

There is no inetd.sec on the system. Is it possible that a network card going bad would cause the server not to be able to telnet to certain IP addresses? Things were working fine a couple of weeks ago and now just on this one machine it is not allowing to telnet to certain addresses.

Is there some sort of pattern to "certain addresses"? That would indicate a routing problem, perhaps external to the machine itself. Do other things besides telnet work? What about ping, traceroute, ssh?

Are you using DHCP? Did the machine's IP address change, like, for instance, not so coincidentally around the time the problems started?

Do you have working reverse DNS, and do the other machines possibly care whether or not you do? Is there anything else on their end which might be preventing the connections?

Cannot FTP or ping. Traceroute does work. Something has obviously changed in configurations somewhere in the systems for this server to not connect to offsite servers like before. Our other one has no problem connecting to the same IP address. This is not a DHCP system and the IP address has not changed.

So on those hosts which you connect to, can you resolve the IP addresses of these two servers? This is just a tangent but I've found that some sites are set up to try reverse DNS, and take a lot of time if it doesn't work. ident would be another thing to look for -- do you have an ident daemon running on one host, but not on the other?

You are saying you can ping by IP address from the OK host, but not from the broken one? That would rule out anything like this. But then you shouldn't be able to traceroute either ...?

I cannot ping from either which is not unusual.
Working Server:Cannot ping, can telnet, can ftp, can traceroute
Server having trouble:Cannot ping, cannot telnet, cannot ftp, can traceroute. The connection problem is only on certain IP addresses, not all on the troubled server only.

How can i know who has telneted to my system and made some changes...?

i want know the ip of user who has telneted before

The fact that traceroute works would seem to suggest that you have a working route and a working network card. I continue to ask: can you resolve the IP address of both servers from the hosts which refuse access from one but not from the other (because that's what I think is going on here)?

this is a new problem. please open a new thread for this!

What exactly do you mean by resolving the IP address? I can't see how an IP conflict is a possibility since I can telnet and ftp to some but not all the hosts from this server. And thank you for being patient with me on all of this.

If the servers are 10.20.30.40 and 10.20.30.41, does "host 10.20.30.40" return the name of the one server, and does "host 10.20.30.41" return the name of the other? That's reverse DNS, mapping an IP address back to the name of the host. (Use nslookup or dig instead of host, equivalently.)