by Hi, all! Remember my dire post on emacs swallowing up the ^S and ^Q
characters when I was modemming into my school and telnetting into my
Internet-connected Linux box via our school's terminal servers? I
struggled with this for weeks. Well, I finally came to a solution,
thanks to Charles Hedrick, who recognized this problem and went to
great lengths to fix the many original coding errors which caused it.
I'm including my notes on how to use his patches to recompile a new
telnetd daemon so Emacs/Mg/others will work.
Thanks to all those who responded, but especially those who
recognized this as a legitimate bug, and not my general incompetence.
Let me know your experiences. Believe me, I want to know if doing it
this way does not work for you, so I can change the directions and
By the way, I only had this problem with CISCO terminal servers.
Granted, the problem *was* with Linux, but telnetting into my Linux
box from elsewhere did not create these problems. I played with the
debugging reports for days, and even had some of our support staff here
at UCI volunteer their time to look at it (thanks, Mike Richey! :)
Since the original bugs had to do with telnet protocol negotiation and
switching of flow control flags, it is highly likely that CISCO
servers negotiate TELNET protocol slightly differently, and that this
is what made the difference in my case.
Which brings me to a lesson I picked up about human (or at least
North American) behavior:
This is what is called in statistics an 'interactional' problem:
Linux works fine *most* of the time (which is why most of you haven't
noticed this bug). The CISCO servers work fine *most* of the time,
(which is why our support staff here at UCI had not heard of the
problem). But when Linux and a CISCO terminal server interact, they do
not successfully negotiate flow control. Interactional problems are
inherently difficult to diagnose (some day I'll write a book,
co-authored by Clifford Stoll: Cuckoo's Egg II). I think we as humans
prefer single-cause problems.
Please let me know if you had a similar experience. For reference, I
was working with SLS 0.99pl12. Do all this as root, of course..
HOW TO REVIVE ^S/^Q IN EMACS/MG/ETC. WHEN TELNETTING INTO A LINUX BOX:
======================================================================
Basically, this fix involves applying the patches from Charles to the
ancestral headers used to build telnetd, and then recompiling telnetd.
============
1) Get these two distributions from tsx-11.mit.edu:
a) /pub/linux/packages/net/net2/sources/telnet/telnet-552.tar.z
(for the patches which fix this problem)
b) /pub/linux/packages/net/new-net2/telnet-rlogin.tar.z
(for telnetd source, if you do not have it in your
/usr/src/net-src/telnet directory, or if, as in my
case, it would not compile)
Doesn't matter where you untar them, though in the end, the contents
of the first ended up for me in /usr/src/net-src/telnet, and the
second ended up in /usr/src/net-src/export.
2) Untar them with tar -xvf <filename>
3) Read the README file from Charles Hedrick in the export directory.
Apply the patches with chr_drv.diff and termios.diff as he's said to.
3a) I'm not sure whether there are other programs (besides telnetd) which
these header files (which the diff files apply to) affect, so I went
ahead and recompiled my kernel, too (including the make clean
command). You may have success without this step. I don't know enough
about where these headers are used.
4) After applying the patches from telnet-rlogin.tar.z, then go to the
telnet-552.tar.z source, and recompile telnetd (since it will be using
the header files you've just patched.) I believe it expects to run
from the termcap file, though I took out the -DTERMCAP flag in the
Linux section of the Config.generic file, so as to run from terminfo,
which I prefer. Your choice, here. (Warning, I believe telnetd will
still compile if you take out this flag, but telnet will not. I didn't
care. Telnet was not broken, so I didn't need a new one.)
5) cp /etc/telnetd /etc/telnetd.old
6) cp telnetd /etc/telnetd
^---the one you've just made.
7) PLAN A:
Comment out your old telnet line in /etc/inetd.conf and replace with:
telnet stream tcp nowait root /etc/telnetd telnetd
PLAN B:
(The above does, of course, bypass security lockouts via hosts.deny and
hosts.allow via /usr/etc/tcpd, but I do not lock out specific machines
anyway. If you wanted to keep your old tcpd format, you could
probably use this line instead, but I haven't tried it:
telnet stream tcp nowait root /usr/etc/tcpd in.telnetd
This is in fact the way that SLS is shipped, I believe. Just remember
that if you keep it this way, use the in.telnetd that comes with SLS,
don't use Charles': His in.telnetd *includes* telnetd in it, instead
of *calling* another telnetd. This is, I believe, non-standard. Thus,
if you used Charles' in.telnetd (the one from telnetd-rlogin.tar.z)
what would happen is you would not end up calling the telnetd from
Pete's distribution (telnet-552.tar.z) which you just compiled and
copied over. I know, it's wierd, but Charles himself recommends that
you not use his in.telnetd, to just apply the patches he gives you in
steps 1) and 2) of the README, but to use Pete's telnetd, since it
includes the newer telnetd features.)
8) ps -ax (look for the process number for inetd. Suppose you find out
it's 35).
9) kill -HUP 35 (restarts inetd)
10) Log out, log back in. Should be done.
--
===========================================================================
"Timex Sinclair UNIX.. coming soon to a dealer near you."
===========================================================================