Very Computer

I have a linux box at home connected to the net via my ISP (io.com).
When I try to telnet into the linux box from a shell account on my ISP, I
can get in fine. But when I try to telnet from my work account (on a Solaris
box), I connect, I get the message below every time:

$telnet 199.170.92.12
Trying 199.170.92.12...
Connected to 199.170.92.12.
Escape character is '^]'.
Connection closed by foreign host.

I don't have anything in my hosts.allow or hosts.deny files, and my work
machine is in my hosts file. My inetd.conf file has what appears to be a
normal entry for telnet:
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

I'm fresh out of ideas. Has anyone seen this before, or have any idea
what might be going on?

BTW, this Linux machine is a pretty much stock install of the latest
Slackware distribution.

Thanks for any help,

Paul Archer

--
---------------------------------------------------------------------
On the side of the software box, in the "System Requirements" section,
it said "Requires Windows 95 or better".  So I installed Linux.
---------------------------------------------------------------------

Jeff Carter

From what I've read, if tcpd was compiled with the "PARANOID" option
then it will never allow connections from machines with broken DNS
entries even if the hosts.* files allow all clients.

If my diagnosis is correct then you must one of the following:

  Stop using tcpd
  Recompile it without the PARANOID option
  Fix then DNS entry for you Solaris box.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/

You may be the victim of a broken in.telnetd..  There is a documented
bug related to the /etc/termcap file..  If there is no entry for the
terminal type that your telnet client reports, the in.telnetd may dump
core (check in / for a core file)..

Quote:>I have a linux box at home connected to the net via my ISP (io.com).
>When I try to telnet into the linux box from a shell account on my ISP, I
>can get in fine. But when I try to telnet from my work account (on a Solaris
>box), I connect, I get the message below every time:

>$telnet 199.170.92.12
>Trying 199.170.92.12...
>Connected to 199.170.92.12.
>Escape character is '^]'.
>Connection closed by foreign host.

>I don't have anything in my hosts.allow or hosts.deny files, and my work
>machine is in my hosts file. My inetd.conf file has what appears to be a
>normal entry for telnet:
>telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

>I'm fresh out of ideas. Has anyone seen this before, or have any idea
>what might be going on?

>BTW, this Linux machine is a pretty much stock install of the latest
>Slackware distribution.

>Thanks for any help,

>Paul Archer

>--
>---------------------------------------------------------------------
>On the side of the software box, in the "System Requirements" section,
>it said "Requires Windows 95 or better".  So I installed Linux.
>---------------------------------------------------------------------

This was it exactly. I changed my TERM setting and got right in.

Thanks a lot!

Paul Archer

Please tell me what you did!

        I have the same problem.  When I try to telnet to my linux box, I am
not allowed to login.  I have consulted with a fellow who gave me the
exact same advice, to remove tcpd and run in.telnetd directly.  
        However, If just I can just do what you did then I can keep tcpd.  did
you use "stty term=vt100" or is it another configuration that you
changed.

[snip]

Quote:>    However, If just I can just do what you did then I can keep tcpd.  did
>you use "stty term=vt100" or is it another configuration that you
>changed.

csh/tcsh:
setenv TERM vt100;set term=vt100

[snippage]

Also, there's some sites that insist on naming their systems:

mail_host.foo.com
station_1.foo.com
station_2.foo.com
etc.

Underscores aren't allowed in the hostname.  If all the previously posted
ideas didn't work, check on that.

-- DN