telnet session cannot be established

[Marcin Wicinski]

Hi,
Have you ever seen following telnet response:

# telnet 192.164.18.1
Trying...
can't resolve open-nameserver
can't resolve open-
nameserver.centro.pl.
Unable to connect to a server:
Connection refused
telnet: Unable to connect to remote
host: Connection refused


ping is OK, telnet to 192.164.18.1 is accepted from another host.

Thanks in advance.

[Ian Dennison_1]

What does an 'nslookup' tell you, on a server that can resolve it and one that can't?

I am thinking that the hostname for the DNS or NIS Server cannot be resolved? Do you have an entry for 'file' in '/etc/nsswitch.conf?'

Cheers, Ian Dennison

[Marcin Wicinski]

Hi,
nslookup works fine - resolves hostnames and IP addresses properly.
nsswitch and resolv.conf are OK.

[Ian Dennison_1]

These seem to walk through how to troubleshoot this type of problem. See what they give you.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xc863c5ea0230d411ade80090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2cf2a14d9abcd4118fef0090279cd0f9,00.html

First question: Can this host telnet to itself (127.0.0.1)?

Cheers, Ian Dennison

[K.Vijayaragavan.]

Yes i have seen similar errors.

If the telnet service (TCP-PORT-23) is secured in the remote server then we get this error.

in the remote server(192.164.18.1)/etc/inetd.conf telnet service should be enabled (not commented out)

If any entry for telnet service is available /var/adm/inetd.sec file in the remote server then you should make sure it is allowd to your system by specifying "telnet allow ".

If there is any TCP wrappers running on the server that is configured to den access to telnet session then it has to be configured to allow you.

If you are telnetting from other subnet apart from the subnet where the server present ,then also you get the same error.

If you are behind firewall and the firewall is blocking you to do telnet , you will get "connection timed out error".
-Vijay

[Justo Exposito]

Hi Marcin,

Do you check this?
If file /var/adm/inetd.sec does not exist, security is limited to that
implemented by the servers. inetd.sec and the directory /var/adm
should be writable only by their owners. Changes to inetd.sec apply
to any subsequent connections.

PD: This is form the man inetd.sec page.

Regards,

Justo.

[Bill McNAMARA_1]

there is also a patch that was recently introduced that causes telnet pb.s with reflectionX.. that is if you are using reflectionX.

You can search for the problem here by searching for reflection and telnet.. but start by suspecting the services and inetd.

Try telnet'ing locally to the same server.

Later,
Bill

[Sanjay_6]

Hi Marcin,

I don't remeber seeing such a verbose rejection when we do telnet. Most of the time, the message is unable to connect if there is some connection problem. The probable reason for this rejection could be that there are two duplicate ip's on the network. I had a similar problem, where our DHCP was alloting an ip to a NT workstation which was reserved for a server. Out nslookup and all other things were fine, but the duplicate ip was a problem. When we did the telnet from the workstation it used to reject telnet. When we did it from another server it worked. It was weird. anyway we resolved the problem. We were fortunate in locating the problem by going thru the DHCP poool. If you can, can you shutdown the server and then ping the address and see if the ip is replying back. Hope this is not a firewall issue. We had a firewall setup where to connect to some servers of ours, we have to go through another server which is open to these servers, but the rest of the network is isolated.

Hope this helps.

regds

[Marcin Wicinski]

Thank you for all the answares. I solved the problem and it was trivial. I tried to execute telnet with full path and it worked - in /etc/PATH file /opt/socks/bin path preceded /usr/bin path, thus socks telnet was invoked.
Later,

[Roy W Berry]

I've this when ssh is installed on unix servers