Zugg Software :: View topic - [3.10a] Bug: garbled characters at login. MXP vs MCCP

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Hello,

I am a mud administrator. Recently I discovered that CMud showed garbled characters on our login-screen while other clients and zMUD didn't. I traked it down to the order in which I sent the MCCP and MXP (telnet) initiations over the line.

This was broken:
server sends: IAC, WILL, COMPRESS2
server sends: IAC, WILL, MXP
because some characters kept showing (raw debug window) that the MUD surely didnt send.

This seems to work just fine:
server sends: IAC, WILL, MXP
server sends: IAC, WILL, COMPRESS2
(the order here is reversed)

As always these things are difficult to track down, but I hope this information will help you finding the bug.
- xtian

Posted: Sat Oct 17, 2009 4:56 pm

Thanks for the extra info on this! It would help to see the full results from the Raw Input/Output message in the CMUD Script Debugger to see exactly when CMUD is sending the response to this. But I'll keep this in mind when I'm tracking down this bug this week.

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

This seems to be the relevant part. Everything is as I would expect it, but right after the <SB>COMPRESS2<SE> (mccp2 is 86) cmud registeres weird characters. The funny thing is that the mud is really not sending these and turning off the MXP stuff deactivates it. But it seems to be some sort of collusion and timing-conflict between MCCP _and_ MXP.

0.3293 | avadev <<IAC><SB><24><1><IAC><SE><IAC><SB><86><IAC><SE>xÚ<SB><IAC><43><SB><IAC><7><NUL><NUL><NUL><NUL><IAC><IAC><146>Ž6¬²).-(È/*±“Ž6¯<2><NUL><NUL><NUL><IAC><IAC><2><11>”¥<22><21>gæç<5><NUL><NUL><NUL><NUL><IAC><IAC><108>’1oƒ0<16>…<IAC><202>u<9>KI¶.„H‘ÂÔ¦êÀPusê<11>œd<12>²M€<DONT><SB><26>Œ<CR>
0.0001 | HÙîÝ{<247>=<11>1-ZJ²<LF>
0.0001 | —MÃ´îjÅçÍÛß<241>%ŽáB¨<17>~<4><2>i<3>H<18>ÞëªBi˜‚8>…<20>h’<28>8!<20>¢¾1<18>®ß_pÁ;I2¶Ü.î-*8?˜¨å+ÈVq‹<247>˜‰P´(<12><21>ÐÚY×B<24>{gŸß¡äh CÅQîW'X"<28><244> <15>UßìKgd<31>Ù5<WILL><204><1>{2<16><29>µ½…Ý(8©<4>J’&ä8%§<8>ÎyžF³Ÿî<12><246>&<1><EOR>Ï:ZaÉ`<21>°£<248>¸ÇŽrƒ}<245><DONT><19>l#Ø`¿<7>;¹B»Å<6><30>2<30>¿dž<20><8>z,B“«<2>·Ø<20>„Œ/X2O<LF>
0.0002 | ní<16>èv^¡Úpë¡³<ESC>ˆã/<248><15><NUL><NUL><IAC><IAC>

The MXP stuff (from memory) is a telnet-initiation sequence, MXP support, MXP version, MXP username, MXP password, then some MXP custom entities, the rest normal textflow.

Either way you can recreate this when loggin in into our testmud. That is:
avalon.mud.de port 17777
Since this is our development mud, you will not be able to create a character, but you only need to see the login-screen anyway. I will leave that code to an older revision until you let me know (the production mud already has the update that inverses the two negotiations. you can log into to with avalon.mud.de port: 23 or 7777 to compare. but the production mud has also seen other updates in the initialisation screen).

To recreate this bug you need to close the window and reopen it. Simply reconnecting the open window does not reproduce it!

Posted: Mon Oct 19, 2009 8:01 pm

Woohoo! Found the bug in CMUD. Thanks for setting up this test server. I will still use it to test your other bug reports, but this bug is now fixed.

It was an issue whenever there was data left in the packet that turned on the compression. So any data following the SB COMPRESS2 SE was getting processed by CMUD twice...first as compressed text (correct) and second as uncompressed text (wrong).