[vworld-tech] Telnet negotiation

[Patrick Dughi]

> I'm trying to suppress local echo for password entry.  If I transmit:
> 
> IAC,WILL,ECHO
> 
> This suppresses local echo with MS Telnet and Cygwin Telnet (I'm
> assuming the latter is effectively the same as Linux telnet?).
> Presumably this happens because I'm telling the client, "Hey, I'm
> going to echo...so stop".
> 
> But I don't echo, so passwords aren't visible (which is what I want).
> 
> Then to re-enable echo, I do:
> 
> IAC,WONT,ECHO
> 
> On Cygwin telnet, I'm back in business...but in MS Telnet, it's still
> not echoing.  Both implementations report the same things, i.e. they
> respond with IAC,DO,ECHO and IAC,DONT,ECHO, which is expected, but
> obviously both act very differently.
> 
> But once I echo is disabled in MS Telnet, I can't figure out if
> there's any way to re-enable it.  That's a client I'd really like to
> be marginally compatible with.

	I remember encountering two versions of this problem, both with
Microsoft Windows Telnet - one for Windows .. 95? and one for Windows
2000 and up.  Different telnet client programs, each with different
implementations of almost the same problems.  From what I remember, it
was a problem with the client being in line-mode kludge, and echo
incorrectly assuming that 'will echo' implies char mode.

	To get around it, I ended up implementing not only a full
(RFC(s)-compliant) telnet server (as I'm sure you've already done), but
also mimicked the sequence of which a standard Unix-based telnet server
provides.

	That means forcing actual negotiation of the line/kludge/char
mode, and after that, everything worked fairly well.  Then again, the
server I was testing it against used char mode, and so did I.  

	I believe to get it working in linemode, you will just have to
run through a rather intense debugging session.  Use a 'real' client
(not a MUD client, but an actual working implementation of telnet), and
add "set options on" to your telnet session.  This will provide you with
a sequence of working IAC commands and the sort.. You can then look at
what your MS Win client is _really_ doing by examining which options are
actually toggled on and off, and which it only claims are turned on and
off, using status.

	(of course, you enter the options before you connect, or via
control-])

	I see that Jon Leonard has also offered a library of information
about client determination; you can also simply request client side
environmental variables and determine directly without testing.  Just
ask for the "OS".

	PjD