telnet

[Rick Stevens]

roland brouwers wrote:
> Ted Potter wrote:
> 
>>On Tue, 2005-03-29 at 09:23, roland brouwers wrote:
> 
> [snip]
> 
>>>Now, as to why ME behaves differently, I suspect it has to do with the
>>>terminal emulation in its telnet protocol.  One of the last things a
>>>login does is set the prompt string and many systems will "eat" the
>>>first prompt, just due to the way they set up the connections.  I'll
> 
> bet
> 
>>>that it's not necessary for a "CTRL-C", but a simple "ENTER" would get
>>>you the prompt.
>>>
>>>Can you fix it?  Probably not.
> 
> 
>>>As I told you before "ENTER" doesn't work and it is getting worse. It
> 
> is
> 
>>>like eating my network. More and more workstations, even XP are
> 
> waiting
> 
>>>on telnet. If you wait long enough they continue. Some workstations
> 
> that
> 
>>>hat this problem do not anymore. What is this, PACKMAN?
> 
> 
> It's "PacMan" (no "k").  :-)
> 
> First, let's do some preliminary stuff.  Get on the Linux machine and do
> some network probing.  Start out with "netstat -an | grep :23" to see
> how many current telnet sessions you have running.  By default, you're
> limited to 60 concurrent connetions.
> 
> Next, by default, the system will try to log the remote hostname.  If
> your DNS isn't doing reverse lookups or you don't have the Windows
> boxes' IP addresses and hostnames in the Linux server's /etc/hosts file,
> the system will wait for DNS to time out before allowing the session to
> continue.
> 
> Ok, how to fix?  Well, if you have more than 60 concurrent sessions, you
> have to ask yourself if that's a legitimate use (60 telnet sessions is
> a LOT, but it depends on your usage).  If you need more, you need to go
> into /etc/xinetd.d and edit the "telnet" file.  If you need, say, 100
> concurrent telnet sessions, add in a line that reads:
> 
> 	instances             = 100
> 
> If you are having DNS issues, you can disable DNS-related things by
> changing the line:
> 
> 	log_on_failure        += USERID
> 
> to:
> 
> 	log_on_failure        =
> 
> Also, add a line:
> 
> 	log_on_success        -= HOST
> 
> If you started with the original /etc/xinetd.d/telnet file, it should
> look sort of like this after all the editing:
> 
> # default: on
> # description: The telnet server serves telnet sessions; it uses \
> #       unencrypted username/password pairs for authentication.
> service telnet
> {
>          disable = no
> 	instances       = 100
>          flags           = REUSE
>          socket_type     = stream
>          wait            = no
>          user            = root
>          server          = /usr/sbin/in.telnetd
>          log_on_failure  =
> 	log_on_success  -= HOST
> }
> 
> Once you're done with editing the file, save it and execute:
> 
> 	/etc/rc.d/init.d/xinetd restart
> 
> to make xinetd use the new data.
> ------------------------------------------------>
> I will continue tomorrow this installation and I have to solve it.
> So I have some questions:
> How can I know that the linuxserver is using DNS, can I trace it?

DNS is always used if the hostname or IP address in question isn't in
the /etc/hosts file.

> The names of the workstations are not in /etc/hosts. I am using K12ltsp
> which fills it up automatically with some names. Do I have to empty it?

Uh, no.  /etc/hosts should contain the names and IP addresses of
machines that aren't in the DNS system.

> If one client is going somewhere on the internet to look for the server
> and other clients don't, how can I trace this.

I'm not sure what you mean by this.  When you try to hit a website or
something on the internet, the first thing the machine does is check its
/etc/hosts file to see if it has the address.  If it doesn't, then the
system queries the DNS system to get the address.

The only way to trace it is to do a tcpdump on the machine in question:

	tcpdump port 53

That will show any DNS queries or responses sent over the network.

> The server has 2 network cards, one of them is not used at this moment,
> could this be a problem?

It rather depends on the routing and how you have things set up.  We'd
need to see a network diagram to tell you what's going on.

> I only in the testphase, so I am far away from 60 users, so this
> couldn't be the problem.
> 
> Thanks again for any help that will get this network into discipline.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-         Microsoft Windows:  Proof that P.T. Barnum was right       -
----------------------------------------------------------------------