Short: Detection of Telnet-Clients
From: Lars Duening <lars@bearnip.com>
Date: Sat, 02 Mar 2002 16:00:40 -0700
Type: Info
State: New

Subject  :   Re: [MUD-Dev] MUD Protocols?
>From     :   Jon Leonard <jleonard@slimy.com>
Reply-To :   mud-dev@kanga.nu
To       :   mud-dev@kanga.nu
Cc       :   jleonard@frost.slimy.com
Date     :   Tue Feb 26 11:18:31 2002
----------

On Thu, Feb 07, 2002 at 06:00:29AM -0800, Caliban Tiresias Darklock wrote:
> From: "Lars Duening" <lars@bearnip.com>

>> If I were nasty, I'd say that a mud should definitely support the
>> telnet protocol properly.

> But then you'd lose compatibility with a lot of clients. ;P

[sorry for the late reply; I've only recently caught up on MUD-Dev
email]

Actually, I think it is possible to implement a server that is
nearly RFC compliant without causing interoperability problems with
any of the common clients.  (And I would appreciate hearing about
any cases I've missed.)

There have been three particular cases that have given me trouble,
and I think they can be handled adequately:

  1) Microsoft's Telnet client.

    This refuses to negotiate options, and defaults to remote echo,
    sending every character as it is typed.  This is blatantly in
    violation of the RFC, but can be detected by it sending a
    one-character packet early on.  A well behaved client will send
    as its first packet one of:

	A fairly long packet (CR LF pending)
	A packet containing CR LF
	A packet containing a 3-octet option negotiation.

    So I add special handling (local echo) for that one kind of
    packet.  This violates the RFCs, but causes no trouble when
    talking to either compliant clients or line-mode noncompliant
    clients.

  2) Clients that don't implement any option negotiation.

    My reading of the standard is that it's incorrect to send an
    option negotiation if there's an unanswered negotiation of the
    same type outstanding.  So the very first negotiation gets sent
    (and seen on a noncompliant client), but after that the server
    takes a lack of reply as a reason not to send any more.  It'd be
    possible to detect the lack of reply and not attempt to
    negotiate any more options, but since I'm really only interested
    in echo negotiation, I haven't bothered.

  3) Odd newline behavior.

    I've seen the unusual but legal use of CR LF LF to indicate two
    newlines.  I'd mishandled this initially, but it turns out not
    to be too hard to track whether or not the NVT (Network Virtual
    Terminal) is at the first position on the line, and treat LFs
    appropriately.

Are there any clients that aren't properly handled with those cases?
If not, I'd agree with Lars Duening above, that a MUD should indeed
support telnet properly, or at least something very close.

Jon Leonard
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev

-- 
Lars Duening; lars@bearnip.com
PGP Key: http://www.bearnip.com/lars/pgp-lars.asc