[Simh] Question on telnet mantra in simh

[J. David Bryan]

Hi Holger,


On Tuesday, November 9, 2010 at 9:15, Holger Veit wrote:

> while implementing telnet support in my terminal emulator, I came
> across the "Telnet Mantra" in sim_tmxr.c: 
>
> [...]
>
> I think I understand that the simh terminal multiplexer is a server in
> telnet speech, accessed by some sort of telnet client program operated
> by the user. 

The SIMH multiplexer library is intended to implement a Telnet server, but 
it does not.  I had been in contact with Arthur Krewat, the original 
implementor of the module, back in 2007 about this problem.  He stated 
essentially that the code is a hack that worked with the clients in use at 
the time.  No attempt was made at RFC compliance or proper negotiation.

My observations at the time were:

 1. SIMH sends "WILL LINEMODE", "WILL SUPPRESS-GO-AHEAD", and "WILL ECHO",
    but it takes no action based on the acceptance or rejection of these
    offers by the client.  If "WILL ECHO" is accepted with a "DO ECHO",
    for instance, SIMH should start echoing received characters.  It
    doesn't, as far as I can see. 

 2. SIMH sends "WILL BIN" and "DO BIN" to request binary transmission in
    both directions.  It responds to "WONT BIN", meaning no binary
    transmission from terminal to SIMH, but ignores the "DO BIN" or
    "DONT BIN" for the SIMH-to- terminal connection.  Also, it assumes
    binary mode in the absence of a reply (WILL or WONT from the
    terminal), but the RFC requires that it remain in ASCII mode in this
    case. 

 3. SIMH ignores WILL or DO requests it does not understand, rather than
    rejecting them with DONT or WONT (not responding implies that SIMH
    is already in the mode offered -- "If a party receives what appears
    to be a request to enter some mode it is already in, the request
    should not be acknowledged"). 

Rewriting the Telnet code to implement an RFC-compliant server was on my 
"to do" list at the time, but I found that there were complications.  For 
example, the HP terminal emulator "QCTerm" does not follow RFC 854, which 
requires that CR characters be followed either by LF or NUL in ASCII mode.  
QCTerm sends bare CRs, so an RFC-compliant server would lose the first 
character of each line transmitted.  There is a workaround in the code for 
this; see my comment in "sim_tmxr.c".

The priority for creating proper server negotiation dropped for two 
reasons.  First, the current code seems to work with clients in use.  
Second, at least some clients in use aren't RFC-compliant themselves, so 
implementing a strict RFC-compliant server likely would break existing 
configurations and would require workarounds.  So it seemed to be a lot of 
work for marginal benefit.


> So I think, the first line is at best useless, and should be removed,
> or, perhaps better, replaced by a IAC WONT LINEMODE. 

I believe that sending "WONT LINEMODE" upon connection is prohibited by the 
RFC ("Parties may only request a change in option status; i.e., a party may 
not send out a 'request' merely to announce what mode it is in").

                                      -- Dave