[Simh] Console Input was RE: Question on telnet mantra in simh
Dave Wade
dave at dwade.freeserve.co.uk
Thu Nov 11 03:36:16 EST 2010
Folks,
Can I ask what I think is a related question. I have been using the IBM1130
build of SIMH and whilst it does all I need, I found one feature very
frustrating. The 1130 has a builtin Console with a keyboard and golf ball
printer. When using SIMH output gets echoed to the "console" but if you want
to do console you need a telnet session, to which the output is also
directed.
I can understand why this is done, and now have scripts that start this for
me, but I was wondered if it would be possible to modify SIMH to accept
console input from the SIMH console, perhaps by the use of an escape
character. The Hercules 370/390 emulator has this feature. I am quite
willing to do the work, but thought I would ask what folks thought about it
before I started diving through unfamiliar code.
Dave.
> -----Original Message-----
> From: simh-bounces at trailing-edge.com
> [mailto:simh-bounces at trailing-edge.com] On Behalf Of J. David Bryan
> Sent: 11 November 2010 03:18
> To: SIMH List
> Subject: Re: [Simh] Question on telnet mantra in simh
>
>
>
> 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
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
More information about the Simh
mailing list