[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