Telnet failed
eym
I was installed corel linux. I choose server type for the installation.
The installation finished and then I change the IP address from dynamic to
static.
I was try to ping to the linux address and the pinging is ok.
I am trying to telnet from my MS Windows95 to the Corel Linux but the
connection failed(could not open the connection to )
1.Do you why I cannot telnet to linux server?
2.Are there should I have to configure my linux server after the
installation?
Kind regard,
Eka Yan Metta
Rio de Janeiro
have to do some degree of configuration. I also recommend that you learn
more about samba. You need samba to communicate with Microsoft Operating
System.
Hope this helps. Read following Article to do telnet.
From http://uwsg.indiana.edu/linux/LDP/LDP/LG/issue54/tag/3.html
Can't telnet to Linux server
From kd on Mon, 01 May 2000
I recently installed Suse Linux on a machine to be a server, but I cannot
telnet to the linux server from my other machines. can you help?
~kelly
Short answer: Probably TCP Wrappers and the old "double reverse lookup
problem." Try adding an entry in /etc/hosts to refer back to your client(s)
and make sure that your /etc/nsswitch.conf and /etc/hosts.conf are
configured to honor "files" over DNS and NIS.
You could have been a bit more vague. You could have left out the word
"telnet" ?
When asking people technical support questions you have to ask:
How many possible causes are there to this problem? How many of them have I
eliminated? How have I eliminated them? Can I eliminate some more? What is
the error message I'm getting (if any)? What was I expecting? What happened
that didn't match that/those expection(s)?
For example: Can you ping the server from the client system? (That
eliminates many IP addressing, routing, firewall and packet filtering
questions). Can you telnet from that client to any other server? (That
eliminates most of the questions that relate to proper client
software/system configuration and function). Can I access any other service
on this client? (Web server, file or print services, etc.)
Then you ask: What did I expect to happen when I telnetted to that system?
I'd expect to get a set of responses something like:
Trying 123.45.67.89 Connected to myserver.mydomain.not Escape character is
'^]'. Debian GNU/Linux 2.2 myserver.mydomain.not myserver login:
So, what did you get. Did you see the "Trying" line? That would mean that
the telnet DNS or other hostname lookup returned something. Did the IP
address in the trying line match that of your new server? That would mean
that your DNS is correct! Did you get the "connected to" line? That suggests
that the routing is correct. Did it just sit there for a long time? How
long? What if you wait for five or ten minutes? Does it eventually connect?
It sounds like you have the old "double reverse DNS" problem. You are
probably using DNS and you probably don't have proper reverse DNS (PTR)
records for you client system(s). Do a search in the Linux Gazette archives
for several discussions on this.
When you are getting free software and free support, it's important to do
your homework. I typically will put about 10 hours into trying to solve a
problem before I'll write up a question to post to the newsgroups, mailing
lists, authors/maintainers, etc.
Of course I can understand part of the problem you might be facing. It
sounds like you have little or no Linux experience, or at least little or no
experience in setting up Linux networking.
You probaby don't know all of the elements that go into "telnetting into
your server." Here's the basic rundown:
You have to have a client (telnet command). That has to be on a system with
TCP/IP installed, configured and working. It must have an IP address and a
route to your server.
You have to have a server (in.telnetd). It would normally be launched on
demand by a dispatch program (inetd) which would be reading configuration
out of a configuration file (/etc/inetd.conf).
On Linux systems the /etc/inetd.conf is usually configured to run most
programs under an access control and logging utility called "TCP Wrappers"
(/usr/sbin/tcpd). That utility refers to a couple of configuration files
(/etc/hosts.allow, and /etc/hosts.deny) and it does some "paranoid"
consistency checking to try and ensure that the client "is who he claims to
be." The specifics of this paranoid checking are referred to as a "double
reverse DNS lookup."
This requires that the client system's IP address somehow be registered in
some sort of naming service that the server is configured to query. The
easiest of these in most cases is to simply add the appropriate IP address
(and some arbitrary name) int the /etc/hosts file. A better way is to add an
appropriate PTR record to your DNS zone.
Linux uses a modular name services resolution system. Newer versions of
Linux use the /etc/nsswitch.conf files to control the list of name services
that are used for each name space (users/accounts, groups, hosts and
networks, services, mail aliases, file server maps, etc). In most cases you
wouldn't have to modify the nsswitch.conf to make it look at the /etc/hosts
file. In other cases you might.
In previous months I've gone into greater detail about how to troubleshoot
problems in accessing TCP services on Linux systems. Look for references to
tcpdump and strace to find out more.
(Summary: You can replace the entry in /etc/inetd.conf with a wrapper script
that runs 'strace' on the program, thus logging what the program is trying
to do in great detail. You can also run 'tcpdump' on any machine on the
local LAN segment, seeing the traffic between your client and server in
great detail).
Unfortunately these tools are rather advanced, very powerful and
coresponding difficult to use effectively. (You can probably get the
information from them pretty easily -- the problem is to configure them to
provide just the info you need and in parsing and understanding what they
tell you).
Hopefully I've guessed correctly on what you problem is. Otherwise search
through my back issues and the FAQ and do lots of troubleshooting. Ask a
more detailed question.
Corel Technical Services
We have disbaled the telnet server in the Second Edition for security
purposes. You can re-enable it by uncommenting the telnet line in the
/etc/inetd.conf file and restarting the inetd daemon.
Best Regards,
Corel Technical Services
tech...@corel.com