telnet problem using "."

Hi everyone

I need some help for an issue.
I have a network with HP Tru64 Unix servers and Windows servers (DNS resides on Windows)

Just in one of the 15 Unix servers, the commands "telnet ." , "ping ." don't work (please notice the point after the command).
The error says "Names does not resolve to supplied parameters; neither nodename or servername were passed".

Altough it works when I use as parameter either the IP address or the name server, the problem is when . is ussed.

Any idea??? :confused:

Thanks very much :b:

What does an internet name of "." mean?

sorry if I didn't explained it:
you can use . for saying "telnet yourself", for example if I'm in serverA as normal user, and I want to login as root I can say:

[serverA] /home/user> telnet . (instead of using the name serverA)
username: root
password: xxxxx

then the prompt would looks like:
[serverA] /home/user# (now I'm root in the same machine)

The problem is, that for a strange reason, the server does not recognize the "." as itself.. even though if I try with the servername (serverA) or the Ip address the login is succesfull.

I hope this is clear and someone can help me.

  1. Is there anything unique about the client that it does not work on?

  2. do the other /etc/hosts have an entry for "."?

  3. compare /etc/resolv.conf files.

Why don't you use 'localhost' instead of '.' ?
telnet localhost
ping localhost
...
I think '.' is only MSWindows-related and for some things. Even in a MSWindows box you cannot do:
ping .
telnet .

it doesn't work

bye

"telnet ." , "ping ." can be used on Unix, I have 7 more servers and it works fine!!!... the problem is just with this server, which, by the way, has nothing different...

both files: host and resolve.conf are ok, identical to the other servers files.

can someone please help me???? thanks:b:

what is the significance of this command for you? i don't see any reason why you cannot use "localhost" ...

if this is just academic, then look at what's different about this box compared to the other boxes (i.e., os version, patches, software applications installed, etc.) and go from there ...

if this is a production issue --- do the same thing quicker!

good luck!

Unfortunatelly, the significance is not for me, but for my customer.
I do support for this guy, who thinks it is extremelly wird that this command doesn't work in 1 server from 8.
I've already checked : OS is the same (HP-UX)
If nobody can help me, I hope the customer finally forget about it :eek: