12 Apr, 2014, lilmike wrote in the 1st comment:
Votes: 0
Hi all,
I just implemented mccp using KaVir's snippet for negotiation. Now I am trying to make it so mccp is reenabled on copyover/hotreboot, and have that partially working.
The snippet saves all the states of different option to disk fine, and then receives them back from disk fine, as mccp is obviously reenabled, according to the logs. However, when the mud reconnects me, mushclient reports ' unable to decompress text from mud, Incorrect header check'. I'm not yet sure if that is because of the mud having bad data sent, although I'm guessing not as the exact same method is called to start mccp when first connecting, but it gives it nevertheless.
Anyone know what this could mean or why it might happen?
Thanks,
-Michael.
12 Apr, 2014, quixadhal wrote in the 2nd comment:
Votes: 0
You probably won't have any luck maintaining a compression stream across executables. Usually, there is state information kept inside the compression library that you can't preserve. The normal way is to negotiate to turn off compression before the copyover, and then renegotiate to turn it back on afterwards. If the user's client supports a reasonable subset of TELNET, the player won't notice this happening.

It sounds like you aren't disabling it before the copyover.
12 Apr, 2014, lilmike wrote in the 3rd comment:
Votes: 0
Hi,
I believe I am. I don't do any telnet negotiation before copyover to turn off mccp, but then again the spec says all you have to do to turn it off is to end the stream with the z_finish flag.
This I do, as the protocol snippet calls this for me in CopyoverSet() when it gets the data to save to disk. I even confirmed this by printing out the words 'mccp disabled' to the player when there is no text to send but mccp is being turned off, and it indeed displays.
So unless you need to do some kind of telnet negotiation I think I'm doing it all right.
-Michael.
Edit:
This is odd, I just connected in tt++ to make sure it wasn't a mushclient issue, and…
#COMPRESSION END, DISABLING MCCP.
MCCP disabled
#COMPRESSION ERROR, DISABLING MCCP.
Not sure what that's supposed to mean, it says it's disabling mccp then it says mccp error, disabling again.

edit2:
It seems that it is getting the compression error before the copyover actually happens.
For example:
#COMPRESSION END, DISABLING MCCP.
MCCP disabled
#COMPRESSION ERROR, DISABLING MCCP.
copyover initiated by lilmike
[insert a bunch of random garbage here when the mud hotreboots]
This seems like the mud isn't properly ending the stream or something, which seems kind of odd, as it says that the compression has ended properly right there…
12 Apr, 2014, Tijer wrote in the 4th comment:
Votes: 0
had similar issues on my mud… the only client that had this happen to it on was mudlet… i tried to report it to them as its some kind of mishandling of mccp1 and mccp2. Appears that mushclient and z/cmud could handle this fine..

even with turning off compression before copyover and back on afterwards, with mudlet had the random ascii gibberish!!
13 Apr, 2014, lilmike wrote in the 5th comment:
Votes: 0
Unfortunately for my mud it happens on both tt++ and mushclient. Haven't tried anything else.
-Michael.
17 Apr, 2014, lilmike wrote in the 6th comment:
Votes: 0
Hi all,
I've got a little more info as to where it's happening.
First of all, I call the copyover command, which eventually calls CopyoverGet, which turns off compression. Then it seems to send IAC do TTYPE, according to tt++ in debug telnet mode. Then right after that it sends IAC SB MCCP2 IAC SE, which is only ever sent from one place in my code (I added it to the end of the PerformSubnegotiation function) so when I send PerformSubnegotiation(apDescriptor, TELOPT_MCCP, NULL, 0), it sends IAC SB MCCP2 IAC SE. I couldn't figure out right away where the code would send IAC do TTYPE in the middle of the code, although I grepped for usages of PerformSubnegotiation with mccp, and ProtocolNegoatiate, neither of which seem to be called in any weird places. KaVir, perhaps you can enlighten me as to where the protocol snippet would (if it's even supposed to) send IAC do TTYPE before or after a copyover?
Thanks,
-Michael.
17 Apr, 2014, KaVir wrote in the 7th comment:
Votes: 0
lilmike said:
KaVir, perhaps you can enlighten me as to where the protocol snippet would (if it's even supposed to) send IAC do TTYPE before or after a copyover?

It shouldn't. As explained in the copyover instructions in the README.TXT, "The problem with [copyover] is that the client can't detect it, and because clients need to protect against negotiation loops they may end up ignoring your attempts to renegotiate." For TTYPE specifically, renegotiation can cause windows telnet clients to freeze (because they'll cycle into the VTNT terminal type), and other clients may not cycle back to the beginning after the initial negotiation.

In the README.TXT instructions I recommended saving the client name in the pfile. You don't have to store it there, but if you want to maintain it through copyover you will need to save it somewhere - you can't reliably renegotiate it. That's the reason why I added the copyover functions in the first place.

On the MUSHclient forums, Dentin suggested writing a temporary command for switching compression on and off. That would be my suggestion as well - it'll make it much easier to pinpoint the problem. MCCP and copyover can be a tricky combination, particularly when you're adding a load of other protocols at the same time.
17 Apr, 2014, lilmike wrote in the 8th comment:
Votes: 0
KaVir said:
On the MUSHclient forums, Dentin suggested writing a temporary command for switching compression on and off. That would be my suggestion as well - it'll make it much easier to pinpoint the problem. MCCP and copyover can be a tricky combination, particularly when you're adding a load of other protocols at the same time.


I will do that probably, but at this point I'm farely confident that it's not the compression I'm doing itself, as it sends IAC SB mccp IAC SE, which is actually not sent from anywhere in my compression functions. It is, instead, sent from the protocol handler before it turns on compression. I'll probably move it to compressStart when I get a chance, but for some reason that was breaking things so I left it as it is.
E.G.
case TELOPT_MCCP:
if(a == (char)do) {
//send will mccp here, if required
PerformSubnegotiation(apDescriptor, TELOPT_MCCP, NULL, 0); //added code here to send IAC SB mccp IAC SE
// continue with the rest of the code, including compressStart


And since it is sending IAC SB mccp IAc SE according to tt++, I don't see it being anywhere else.
But yeah, I'll probably do the command just to make sure.
-Michael.
17 Apr, 2014, lilmike wrote in the 9th comment:
Votes: 0
Well, turns out it had to do with how I was sending it through the protocol snippet. When I moved it out of there, it works like a charm.
Thanks all!
-Michael.
0.0/9