*Trying 192.168.1.1…
Connected to 192.168.1.1.
username:
admin@linux-tlpp:~> cat /proc/version
Linux version 4.12.14-lp151.28.7-default gcc version 7.4.0 (SUSE Linux)
admin@linux-tlpp:~> time telnet 127.0.0.1
Trying 127.0.0.1…
telnet: connect to address 127.0.0.1: Connection refused
real 0m5,068s
user 0m0,002s
sys 0m0,000s
I can only speculate here, but any delay with authenticating will be down to the server you’re connecting to, so that’s probably where you should focus your attention. This could be a security mechanism to limit brute force attack attempts for example.
I have no idea why you have that delay, but I get the impression you are looking in the wrong direction. As you use IP addresses and not host names, DNS has no role here and thus neither /etc/resolv.conf, nor /etc/nsswitch.conf are of importance.
As I have no telnet deamons running (SSH only), I can not try to re-create your problem here to a listening deamon. But
henk@boven:~> telnet 10.0.0.138
Trying 10.0.0.138...
telnet: connect to address 10.0.0.138: Connection refused
henk@boven:~> telnet 10.0.0.44
Trying 10.0.0.44...
telnet: connect to address 10.0.0.44: No route to host
henk@boven:~>
The first system exists, runs, but has no listening telnet port and has no delay at all
The second system does not exist at all and has a delay (time out) after Trying …, which looks logical to me.
That means your machine sent a hostname query to your DNS,
And your DNS doesn’t have a reverse lookup zone configured.
That’s curious that your machine might read an IP address as a hostname and not as an IP address…
Are you sure your machine is set up for same network (and netmask) so that if the remote address isn’t on your network that your machine knows to use your DG?
eg
If your machine has an address 192.168.2.1/16
and the machine with address 192.168.1.1 is on another physical network.
Please Tony, read above why we use this DNS lookup. It is only to find out of a (any) reversed lookup gives an uwanted delay as encoutered in the OPs telnet session. If there is a answer or a “not found” is of no importance here.
The warning about running telnet server is based entirely on the very first post.
The part about doing a reverse lookup, I’m not clear what you were trying to investigate, machines fundamentally communicate by MAC address and on top of that the IP address… Machines don’t actually communicate by name so names have to be resolved to IP addresses… but the reverse isn’t typically true. Bottom line, a reverse lookup wouldn’t happen for an attempted telnet connection, reverse lookups are useful only for more complex analytical applications, not simple network connections.
Typically, latencies for simple connections like telnet are network related, typically not system.
So, recommend using the most obvious tool for initially testing latency… PING and if you’re traversing multiple routers, traceroute.
I agree with that, but the OP has the idea that the delay is due to a reverse lookup. Thus, instead of telling him that there is no reverse lookup for a telnet by IP address (which he may believe or not), I offered him a way to test himself with a clean reverse lookup, the result of which, his own test, he most probably will believe.
BTW, I use telnet also only as you described above. But the OP has this problem, thus I try to help him. In the mean time hinting him (by telling I only use SSH) that there may be a better way then using telnet. But again, that is not his problem.
Telnet 192.168.0.1 is how I used to connect to my old routers, before the current and previous. Is 192.168.1.1 your router? Telnet is how I connect to my two STBs with 15.1. I get no delay anywhere.