You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original issue 662 created by brazilofmux on 2011-05-15T00:43:38.000Z:
What version of the server are you using? MUX 2.10.0.5 Alpha. (Test host: shangrila.mushpark.com:9999)
What steps will reproduce the problem?
Connect to MUX server with a client that will respond positively to both [IAC WILL CHARSET] and [IAC DO CHARSET].
Arrange for the client to send [IAC SB CHARSET REQUEST <> IAC SE] immediately after it replies to the server's [IAC DO CHARSET] with [IAC WILL CHARSET].
A log of this from my client's console, trimmed to only CHARSET related log lines, is below. The "Telnet Irregularity" line refers to the console log message beneath it. Note the order of the messages: first the client sends REQUEST, then the server sends REQUEST, then both reply. If the server replied to the client's REQUEST before sending its own, this issue would not apply; it would just be a renegotiation initiated by the server.
What is the expected output?
According to RFC2066 page 9 (quoted below) when a server and client simultaneously send [IAC SB CHARSET REQUEST <> IAC SE] stanzas, the server MUST reject the client's request, and the client MUST respond normally to the server's request.
What output do you see instead?
MUX replies to the client's request with [IAC SB CHARSET ACCEPTED <> IAC SE] rather than [IAC SB CHARSET REJECTED IAC SE].
Please provide any additional information below.
Quote from the relevant paragraph of RFC2066:
"In some cases, both the server and the client systems are able to perform translations and to send and receive in the character set(s) expected by the other side. In such cases, either side can request that the other use the character set it prefers. When both sides simultaneously make such a request (send CHARSET REQUEST messages), the server MUST reject the client's request by sending a CHARSET REJECTED message. The client system MUST respond to the server's request. (See the CHARSET REQUEST description, above.)"
It is unlikely that most clients will run into this issue, and the ones that do encounter it probably have robust enough telnet option handling that it won't cause a major problem - my client simply allows the invalid ACCEPTED as though it were valid, for example. This is a minor bug, but fixing it should have little to no impact on existing clients.
The text was updated successfully, but these errors were encountered:
Original issue 662 created by brazilofmux on 2011-05-15T00:43:38.000Z:
What version of the server are you using? MUX 2.10.0.5 Alpha. (Test host: shangrila.mushpark.com:9999)
What steps will reproduce the problem?
A log of this from my client's console, trimmed to only CHARSET related log lines, is below. The "Telnet Irregularity" line refers to the console log message beneath it. Note the order of the messages: first the client sends REQUEST, then the server sends REQUEST, then both reply. If the server replied to the client's REQUEST before sending its own, this issue would not apply; it would just be a renegotiation initiated by the server.
2011-05-14 18:16:55.444 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC WILL CHARSET.
2011-05-14 18:16:55.445 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC DO CHARSET.
2011-05-14 18:16:55.445 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC DO CHARSET.
2011-05-14 18:16:55.446 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC WILL CHARSET.
2011-05-14 18:16:55.446 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC SB CHARSET REQUEST <UTF-8 ISO-8859-1 US-ASCII> IAC SE.
2011-05-14 18:16:57.288 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC SB CHARSET REQUEST <UTF-8 ISO-8859-1 ISO-8859-2 US-ASCII CP437> IAC SE.
2011-05-14 18:16:57.290 Koan[30913:a0f] [shangrila.mushpark.com:9999] Sent: IAC SB CHARSET ACCEPTED UTF-8 IAC SE.
2011-05-14 18:16:57.291 Koan[30913:a0f] [shangrila.mushpark.com:9999] Telnet irregularity: Received CHARSET ACCEPTED subnegotiation, but no active negotiation in progress.
2011-05-14 18:16:57.292 Koan[30913:a0f] [shangrila.mushpark.com:9999] Received: IAC SB CHARSET ACCEPTED UTF-8 IAC SE.
What is the expected output?
According to RFC2066 page 9 (quoted below) when a server and client simultaneously send [IAC SB CHARSET REQUEST <> IAC SE] stanzas, the server MUST reject the client's request, and the client MUST respond normally to the server's request.
What output do you see instead?
MUX replies to the client's request with [IAC SB CHARSET ACCEPTED <> IAC SE] rather than [IAC SB CHARSET REJECTED IAC SE].
Please provide any additional information below.
Quote from the relevant paragraph of RFC2066:
"In some cases, both the server and the client systems are able to perform translations and to send and receive in the character set(s) expected by the other side. In such cases, either side can request that the other use the character set it prefers. When both sides simultaneously make such a request (send CHARSET REQUEST messages), the server MUST reject the client's request by sending a CHARSET REJECTED message. The client system MUST respond to the server's request. (See the CHARSET REQUEST description, above.)"
It is unlikely that most clients will run into this issue, and the ones that do encounter it probably have robust enough telnet option handling that it won't cause a major problem - my client simply allows the invalid ACCEPTED as though it were valid, for example. This is a minor bug, but fixing it should have little to no impact on existing clients.
The text was updated successfully, but these errors were encountered: