"Mark Hobley" wrote
> Joe Hesse wrote:
> >
> > The problem is when I try to connect to the telnet server from one or more
> > client computers on the same local network. Here is what happens.
> >
> > $ telnet 192.168.0.100
> > Trying 192.168.0.100...
> > Connected to 192.168.0.100.
> > Escape character is '^]'.
> > getnameinfo: localhost: Success
> > Temporary failure in name resolution: Illegal seek
> > Connection closed by foreign host.
>
> I am taking a complete guess here, but try this. On both machines, edit
> /etc/hosts and add the line:
>
> 192.168.0.100 scooby.joehesse.lan scooby
>
> Regards,
>
> Mark.
>
> --
> Mark Hobley
> 393 Quinton Road West
> QUINTON
> Birmingham
> B32 1QE
>
> Email: markhobley at hotpop dot donottypethisbit com
>
> http://markhobley.yi.org/
>
I second the notion; the message is probably issued by the telnet server box,
doing some name or ipaddress-to-name lookup, and hopefully priming the
hosts file will make that lookup succeed. If that is a good guess, then you
can speed up your testing by sitting at the telnet server console and making
sure that you don't get the dreaded "illegal seek" response when you try to
do host 192.168.0.100 or whatever it is you type to get a name for a known
ip address, and that you can attempt ping -c 1 scooby
without it complaining it cannot convert that name to an ip address. Erm, scooby
should probably be changed here to whatever the telnet distant client claims is
his hostname. Also, see if you can find a logged barf in like /var/log/messages
I guess when you do the doomed telnet attempt, to firm up the guess that this is
a dns lookup failure; the context of such a log entry may help suggest how to
either prevent or facilitate this seemingly overzealous chunk of the operating system.
Umm, if the new entry in /etc/hosts file on telnet server box doesn't enable the dns
tests I suggested, you may need to tweak something like /etc/nsswitch.conf so
hosts file takes priority over bind dns info...
Other info I googled suggested switching to a kerberos telnet server, but I wonder
if that would be rigged to work ok even if you don't use kerberos at your shop?
I'm guessing that selinux or something is just wanting to be helpful and log the start
of a telnet session with the optional details of "what is the hostname?" of the distant telnet
client box. Also, it is indeed cryptic to see the term 'invalid seek', but I did see the
phrase mentioned in some blog referring to some weird ldap
thing, about trying to get some associated group membership info where the group it
defaults to did not exist...
As long as you're already scoffing at accepted security practices, you _do_ know that
linux is going to lie to you and claim 'that is the wrong password!' when you're logging in
as userid root, right? Because you're coming in on 'device' pts/0 or pts/1 or etc...
and those aren't cited in /etc/securetty file. In truly 'trust me, this is a friendly
campus'
situations, I just delete or rename /etc/securetty and rhel4 at least has been willing to let
me telnet in as root on any device whatsoever, just some minor gripes in log files about the
missing securetty...
Similar Threads
Linear Mode
