-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reversed roles with CHARSET negotiation #59
Comments
@amotzkau can you suggest any telnet client and server that supports CHARSET negotiation? I vaguely remember implementing against "Atlantis" MUD telnet client, which was the only reference I could find compatible with my computers at the time I developed it. |
Mud clients (that I know of):
Except the one that we have, I'm not aware of servers implementing that:
|
Would this bug be causing us to hit
Here's what Mudlet saw:
Here are the complete session logs from the server side:
|
I might consider just removing charset temporarily until a correct implementation can tested. |
That may be safest. Probably not of much consolation, but Mudlet somehow ends up in the correct state despite the non-compliant negotiation! |
Yeah I see that in the logs I've got mudlet installed and I hope to work it out over the weekend for next release |
Cool! I was trying to take a shot at this but my unfamiliarity with the codebase made it impossible in the time I had. Happy to help test and refine once you've got the basics in place! |
It seems that telnetlib3 sends the CHARSET subnegotiation upon receiving a WILL CHARSET (and waits for the subnegotiation after receiving a DO CHARSET).
RFC 2066 says about the IAC SB CHARSET REQUEST:
This is exactly the other way around.
And it also seems that telnetlib3 doesn't respond to a WILL CHARSET with a DO CHARSET, which I think it should.
The text was updated successfully, but these errors were encountered: