cross platform telnet question

[Chris Bopp]

Dear mmn (is that your name?):

When I first saw your question, I began to write
a response and realized that I was simply restating
things from the following (much more authoritative)
sources:

--- There is probably enough right here
The Linux Networking HOWTO (formerly the NET-3 HOWTO):
http://howto.tucows.com/otherhowto/NET3-4-HOWTO

--- Unless you think the Linux hardware itself is not setup:
The Ethernet HOWTO:
http://howto.tucows.com/LDP/HOWTO/Ethernet-HOWTO.html

--- Not Linux-specific, but excellent ground-up expo
--- and Olaf Kirsch is a god
The Network Administrator's Guide (NAG)
http://howto.tucows.com/LDP/LDP/nag/index.html

--- Short list of big documents, including the NAG
Page of guide links at TUCOWS:
http://howto.tucows.com/guides.html

--- Long list of pointers to specialized stuff;
--- Masquerade, Appletalk, etc.
The Linux Networking Overview HOWTO:
http://howto.tucows.com/otherhowto/Networking-Overview-HOWTO

If I were you, I would try things until something breaks,
rather than ask what to try. It is easier for people to
speculate about the cause of a problem than it is to
recommend how to avoid problems.

BUT...if you're still reading, I suggest this (ordered) list
of things to try:

1) Gotta make sure networking is up on Linux. Usually the best
measure of this is to use the "ifconfig" program to look at the
current interfaces, and if you don't see an "eth0" interface,
use an
 # ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
and see if "ifconfig" shows an "eth0" interface then. If ifconfig
won't configure or show a physical (not "lo") interface, then
read the Ethernet HOWTO.

2) Once ifconfig shows an "eth0" interface with reasonable numbers,
(See the Networking HOWTO or the NAG for elaboration), try
pinging eth0's IP number; something like this:
 # ping 192.168.1.1
If you can't ping your local eth0, see the HOWTO or NAG.

3) Once you CAN ping your local eth0, see if there's a telnet
server listening:
 # netstat -an
Look for some lines like this:

  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State      
  tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      

That would be a tcp service listening to port 23
(the well-known Telnet port) on all interfaces.
It's probably inetd, not telnetd itself, but you
MUST see a line like this or there's no hope.

4) Once someone's listening on port 23, try it:
 # telnet 127.0.0.1
and see if you can connect to yourself. Some people
would put this step first, before bothering with eth0
and stuff, but who cares what some people think?
If it doesn't work, try "telnet -v", and snoop around
files in /var/log/ for error messages from inetd or
telnetd as to why it won't respond.

5) Once you can connect locally, you want to ping
the Linux eth0's IP address from another machine.
Does Mac have a ping? I don't know. Configure the
Mac TCP/IP to be 192.168.1.2 or some other IP that
is different, but a close neighbor of the Linux IP,
 and try to ping the Mac IP from the Linux:
 # ping 192.168.1.2

6) When that works (double-check the "ifconfig"
settings for eth0 in Linux and the TCP/IP control
panel in the Mac, and then try a different cable),
go to the Mac and use Nifty Telnet to connect to
the Linux IP address (192.168.1.1 in this example)

7) Name resolution is harder, and is covered in the
HOWTO and the NAG above. Linux and Mac and Windows
can use text files as a substitute (hosts file),
but the Mac needs a different format - rather like
a DNS zone file.  The Mac Help system will lead you
to the Apple site with instructions for this.
I definitely recommend hosts files instead of DNS
at least until you get telnet working!

Try it with the PC - just telnet 192.168.1.1.

8) If you got steps 1-5 OK and each machine can
ping the other by number (possibly by name if
you play with the hosts file at each end), and
something's listening on TCP port 23, and 
telnet still doesn't work, it could be several
things. I won't bother to enumerate them. The
telnet server may be refuse connections if it
is unable to complete a IP-number-to-hostname
translation; signs of this would appear at the
end of log files in /var/log/.

write back to the list with success/failure! bye!

Chris Bopp