From: Howard Chu on
It's been over 10 years since I looked at this last

http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html

and apparently no one else has been interested since then. A random
conversation got me looking into it again, and now I have it working. However,
obviously the world has moved on from telnet to ssh, and my goal in posting
now is to hash out what needs to be done in the kernel so that LINEMODE can be
fully supported in ssh.

First you'll note that this patch is fairly similar to the one I posted back
in 1999. The bug I was chasing down back then turned out to be in the telnetd
source, not in the tty driver, so this patch has only needed minor refreshing
to bring it up to date.

There are some other issues that need to be addressed though to make this
feature maximally useful today:

GNU readline and other similar code is prevalent today, and uses many
additional editing characters that aren't represented in termios. The telnet
Linemode spec in RFC 1184 accomodates most of these characters but without
termios support there's no way to communicate these settings between telnetd
and the readline library (or whatever other app). Most of the editing features
provided by readline really belong on the local client anyway.

Linemode assumes single-character codes for input functions, but on common
terminals (e.g. ANSI/VT100 style) a lot of navigation keys send
multi-character sequences (cursor movement, etc.).

So I'm looking for suggestions on ways to approach this, that will allow as
much functionality as possible to be handled by a local client.

Despite the fact that most people today have ready access to high speed
broadband networking today, I think the motivation for local character
processing is as great now as it was 10 years ago. I regularly use an ssh
client on an Android phone to keep tabs on my servers when I'm away from my
home base, and sometimes cellphone connectivity can be extremely lossy,
networks can be heavily congested, etc... Waiting for character-at-a-time
packet turnarounds in these conditions can be pretty aggravating. Also, if
you're unfortunate enough to need to get access to a machine while you're
roaming away from your home network, the per-byte roaming fees can be murder.
Both of these pain points can be minimized by using local character processing
and only sending complete lines to the remote server.

The telnet Linemode spec serves as a pretty good starting point for adapting
to ssh, but these details still need to be addressed - can/should we add
additional command characters to the tty driver? The telnet spec defines these
commands that the tty driver is missing:
Move cursor one character left, right
Move cursor one word left, right
Move cursor to beginning/end of line
Enter insert/overstrike mode
Erase character to the right
Erase word to the right
Erase to beginning/end of line

Also it would be nice to be able to define other forwarding characters, which
don't necessarily have an edit function. E.g., <TAB> for word completion.

Another feature with readline is a command history buffer that can be reviewed
using Cursor Up/Down. Can/should we define this in the tty driver too? Or
perhaps rely on the client to implement its own command buffer, and never
mention this aspect on the wire protocol. Again, given the purpose, it makes
most sense to me to keep this feature on the client side. But some
coordination with the server would still be useful. E.g., different programs
can maintain their own persistent command history files. It might be nice to
have a way for the app to signal to the client which command context to use
for the current history buffer, and keep them all separate. (Or not, I can see
other times where you'd just rather have it all as one stack.)

PS: if anyone knows where to send the patches for telnetd, please email me.
Looks like the upstream source hasn't been touched since 2000.

ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/