Zugg Software :: View topic

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I originally thought this was the same bug as in this thread. However, based on Zugg's posts there, I now think it is a separate problem. My posts from that thread are yanked and placed below:

I am seeing a lockup trying to connect to MozartMUD (mozartmud.com:4500), immediately after MXP is enabled. I have a reproducible test case, detailed below, which can be invoked at character creation time:

Note: I have performed this test on two separate installs on two separate machines. Both were virgin installs of 2.21 (new directory, all data files in the install directory, no imports of anything), to reduce any crossover from zMud or previous CMUDs, but I do not have a virgin machine (which has never had zMUD/CMUD installed) to completely eliminate the possibility.

Procedure

Run CMUD
Create a new session named 'Mozart'. Set the hostname to mozartmud.com and the port to 4500. Save changes.
Open the Mozart session.
After the welcome screen, you will see:

Code:

By what name do you wish to be known?
Enter 'Fluglehorn' - I know the name is not taken.
You will see:

Code:

Did I get that right, Fluglehorn (Y/N)?

Confirm by typing 'y'.
You will see:

Code:

New character.
Choose a password for Fluglehorn:

Type 'zzzz'. We'll never finish character creation, so don't sweat it. If the auto-login trigger dialog appears at this point, just cancel it.
You will see:

Code:

Please retype password:

Type 'zzzz' again (or just hit return to re-send it).
You will see:

Code:

Enable MXP (Mud Extension Protocol)? (Y=Yes, N=No):

Type 'y'.
CMUD will lock up and go to 100% CPU (or 50% on my dual-core machine). I have to kill it from the Task Manager.

A similar lockup occurs when logging in an existing character. I have no way of getting at the stack, or otherwise figuring out what it's up to. However, I CAN say that I have not yet enabled MCCP (that's the next question expected in character creation), so that isn't the culprit in my case.

Further info. #DEBUGFILE doesn't give anything terribly useful - I suspect that the final buffer isn't flushed to the file by the time I kill CMUD, so the debug file just cuts off wherever. So I ran the procedure above with Packetyzer running on the connection. Here is the final data packet from the server, and the ACK back from CMUD:

Posted: Mon Mar 31, 2008 9:54 pm

OK, I looked into the problem with MozartMUD, and it looks like they are also sending an incorrect telnet option. This is similar to the bug with Dark Skies, but instead of it being the "valid" v1 of the MCCP protocol (with the documented issue of not terminating the option sequence), MozartMUD is sending the incorrect sequence:

IAC SB 91 SE

In other words, it looks like someone was reading the MCCP v1 spec and somehow decided that this was the proper way to "enable" any protocol. This is a completely bogus code. I don't know if some other MUD client is incorrectly recognizing this sequence to enable MXP or not. zMUD/CMUD do not "enable" the MXP protocol at all. zMUD/CMUD simply use the normal DO/DONT WILL/WONT sequences.

In any case, the above is invalid text for a Telnet connection. Whenever you use IAC SB to start a suboption negotiation, you must ALWAYS end the sequence with IAC SE as in the Telnet RFC. As you can see, the above text is missing the IAC before the trailing SE.

You should notify MozartMUD about this problem since it might cause problems with their MUD and other telnet clients.

The reason this worked in previous versions of CMUD (and zMUD) and that when implementing the v1 MCCP bad code, zMUD/CMUD was allowing any suboption to terminate with just SE instead of IAC SE. I guess I will do this in the next version too so that people can play these bad MUDs. But see, this is what happens when you start allowing exceptions to the proper protocols. You get lazy MUDs, or MUDs that just don't understand the protocols, sending out invalid text. And when MUD clients accept this bad text, it just encourages more MUDs to do it instead of fixing their code properly.

So please report this to Mozart and see if they will fix their code base. Or, if you discover why they are sending this particular code, let me know. Like I said, maybe some other MUD client is handling MXP improperly and they added this since it didn't break zMUD/CMUD in the past.

Posted: Mon Mar 31, 2008 9:59 pm

Btw, the reason that is is *VERY BAD* to kludge CMUD to allow this kind of invalid Telnet text is that it will cause problems for Telnet servers that use the protocol property and actually need to send a chr(240) (SE) in the data stream. Telnet supports sending IAC IAC in order to place a chr(255) into the data stream. So that is why you need IAC SE to mark the end. My terminating the sequence with just SE, it prevents that character from being within the suboption data itself.

So, since MXP doesn't ever use the chr(240) in it's suboption negotiation, I am going to restrict this "fix" so that it only allows the invalid sequence for options 85 (v1 MCCP) and 91 (MXP). Otherwise this might cause problems on IRE MUDs that use suboptions extensively to send data.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Yes, I definitely see the problem. I'll see if I can get a server-side fix as well...maybe they'll let me implement it if they're too busy otherwise. Smile

I have a horrid suspicion, though, that the same problem will rear its head on MSP (telnet option 90) with Mozart or some other MUD - I can't tell until I get past the MXP crash. Perhaps option 90 should be enabled for the kludge as well? Or make it a configuration checkbox somewhere?

Posted: Tue Apr 01, 2008 4:55 pm

Yeah, I'll add MSP to the list too.