[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sheflug] Telnet



>>>>> "Al" == Al Hudson <eah106 [at] york.ac.uk> writes:

    Al> On Mon, 29 May 2000, Ian Wright wrote:

    >> The only thing now which puzzles me is that, as I shut one
    >> machine down completely before exiting the telnet link at the
    >> other machine and this locked the terminal window on that
    >> machine - wouldn't let me close that window until I closed down
    >> the machine - how does a dumb server deal with such things.

You can't close the window, but you can destroy it.  (Closing a window
is like kill -TERM, destroying it is like kill -KILL.)

    Al> Um, off the top of my head I think that's how telnet works,
    Al> although I may be wrong (someone more knowledgeable may want
    Al> to correct me!). I believe telnet works on a 'piecemeal' basis
    Al> - that is, the connection made isn't consistently alive, it
    Al> sends packets as and when needed. There isn't any other clever
    Al> communication between the computers. This means, when the
    Al> computer that you were telnetted to went down, the other one
    Al> has no way of knowing. You can always kill the session with a
    Al> 'kill', or 'kill -9' if it's really bad - just do a 'ps aux |
    Al> grep telnet' to find the telnet process, and kill it. OTOH,
    Al> telnet should realise that the other machine has gone down,
    Al> but it probably takes a while :(

"Forever" _is_ quite a while.  I occasionally have remote shell
sessions (now more often ssh than telnet) with idle times in weeks.  I
assure you I would not be pleased to find them closed, as I have come
to depend on shell histories to manipulate servers and complex
./configure commands and things.

The reason telnet works this way is that there is no way for the
telnet program or the telnet server to distinguish between a dead
partner and a dead network.  So you can do something stupid (say,
`ipchains -F input; ipchains -P input DENY' :-) and recover your
telnet session simply by getting the network back up.  (More usually,
the phone co or your ISP does something stupid.  :-)

Vanilla telnet provides an escape key, usually ctrl-], which allows
you to talk to the telnet program (EVERYTHING else gets sent over the
wire verbatim).  This gives you a "telnet> " prompt.  Type "close"
[the connection] and you're back in business.  (You may have to type
quit or something.)

    Ian> It was the Telnet from both ends at once thing which sorted
    Ian> me out. I hadn't realised that working from one end wouldn't
    Ian> provide a bidirectional link.

You've just discovered the principle of the "firewall".


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.