Am 11.11.2010 05:22, schrieb J. David Bryan:
Rich,
On Wednesday, November 10, 2010 at 23:08, Richard Cornwell wrote:
Here is a patch I sent Bob back in a couple of years ago to fix telnet
support to handle correct negotiations.
I had tried your patch back in October of 2007 when I was looking at
improving the Telnet code, but it had two problems. From my notes at the
time:
1. It causes SIMH to send a "WONT LINEMODE" upon connection, but the RFC
prohibits this ("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").
2. It unconditionally responds to WONT with DO or DONT, which leads to
negotiation loops (e.g., "DO BIN" from SIMH to client, "WONT BIN"
from client, "DONT BIN" to client, "WONT BIN" from client, etc.).
The negotiation loop showed up with the "QCTerm" HP terminal emulator. As
I recall, the RFC suggests that loops may be avoided by ensuring that a
denied request is not repeated.
Hi, David,
I see: here be dragons.
As a non-native speaker, I have problems figuring out what was actually
intended in RFC854/5 with the WILL/WONT and DO/DONT pairs, and it seems
to me that whatever the correct intention was, simh is broken anyway,
beyond incompletely implementing the IAC options negotiation.
In contrast to my idea of having simh report to the client what it does
not like (in contrast to your #2.) simh should only tell what it offers
to handle, so WILL ECHO, WILL BIN, and WILL SGA appears to be okay, but
WILL LINEMODE is not, because simh neither wants to do LINEMODE
suboption negotiation at all nor can it do it at all, so it shouldn't
announce it. However, if the other side would request DO LINEMODE it
should deny it with WONT LINEMODE. The other side is a client, though,
so should not DO LINEMODE at all, according to RFC1184...
For the WILL ECHO/BIN/SGA offers, simh should accordingly react properly
when the other side does not accept the offer. While a WONT BIN from the
client seems to be handled correctly, DO/DONT BIN is not, and the RFC
default mode ASCII is not respected. Neither does it respect a WONT ECHO
reply to the DO ECHO it demands.
I guess the latter flaws can be mended, offering LINEMODE but being
unable to deal with IAC SB LINEMODE xxxx IAC SE is a bad idea, so to
correct my proposal: drop it rather than announcing the converse (WONT
LINEMODE).
Now, I am curious why this line is present at all. Has there been any
client relying on this, or do all present clients deny this offer (which
will then be dropped by simh as it ignores what it does not understand)?
I said it is no big deal to take the offer as an invitation to spam the
emulated machine with the "xxxx" of the suboption context. It sheds some
light on telnet client implementations that this hasn't already happened
apparently.
--
Holger
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
