06 Oct, 2010, Rojan QDel wrote in the 1st comment:
Votes: 0
So I implemented the WickedMUD modified MUD Telopt Handler with MSDP added to it. Everything seems to be working fine, however when MCCP is enabled, it is breaking the MSDP output for some reason. I'm not really sure what the root cause is, but when I disable MCCP then MSDP works fine and when MCCP is enabled I am not seeing any MSDP output even though I know the functions are getting executed due to debug calls.

Does anyone have a suggestion on how to deal with this other than end_compress, send MSDP, and start_compress?
06 Oct, 2010, Rudha wrote in the 2nd comment:
Votes: 0
Sounds like MCCP is compressing out-of-band data too. I'm not knowledgeable enough with WickedMud to suggest a fix, though, I'm afraid.

Maya/Rudha
06 Oct, 2010, Tavish wrote in the 3rd comment:
Votes: 0
What sort of modification have you made? Out of the box it seems to work correctly for although there are some copyover problems.
06 Oct, 2010, Rojan QDel wrote in the 4th comment:
Votes: 0
Yeah, I'm having MCCP copyover problems too with it disconnecting users. But the only modifications I've made is to get it to compile with my codebase and to change the MSDP output.
06 Oct, 2010, Scandum wrote in the 5th comment:
Votes: 0
The MSDP support in WickedMUD is very primitive, but as far as I can tell it still works with MCCP enabled when using TinTin++.
06 Oct, 2010, Rojan QDel wrote in the 6th comment:
Votes: 0
I tested it in TinTin, its only showing MSDP output when MCCP is disabled… Since you wrote the snippet, would you be able to offer any kind of suggestions as to why MCCP might be compressing the out-of-band data?
06 Oct, 2010, Rojan QDel wrote in the 7th comment:
Votes: 0
Figured it out, I wasn't setting up the MCCP string right. However now I am getting some weird memleaks…
/* write compressed */
if (d->mccp)
{
d->outbuf = txt;
d->outtop = length;

return write_compressed(d);
}
06 Oct, 2010, Rojan QDel wrote in the 8th comment:
Votes: 0
This seems to fix it, though opinions on whether it could cause issues would be appreciated:
/* write compressed */
if (d->mccp)
{
strncpy( d->outbuf, txt, length );
return write_compressed(d);
}
06 Oct, 2010, Scandum wrote in the 9th comment:
Votes: 0
Might be you need to use:

strncpy( d->outbuf, txt, length + 1);

in order to get a null byte termination.

And MCCP is supposed to compress all out of band data, including MSDP data.
06 Oct, 2010, Rojan QDel wrote in the 10th comment:
Votes: 0
Using that (or my other option, to be fair):
When I do this in MUSHClient, SendPkt ("\255\250\69\1REPORT\2HEALTH\255\240")

I get this response back: **] BUG: (ident not active)@69.114.19.100 RCVD IAC ?
One issue with this is that it is missing characters at the beginning where it should say Log: [*****] BUG:…Another is that it is thinking it got IAC ? even though the IAC MSDP SB function is being called

When in reality I shouldn't get any bug report since debug_telopts is disabled
06 Oct, 2010, Tavish wrote in the 11th comment:
Votes: 0
Rojan QDel said:
Using that (or my other option, to be fair):
When I do this in MUSHClient, SendPkt ("\255\250\69\1REPORT\2HEALTH\255\240")

I get this response back: **] BUG: (ident not active)@69.114.19.100 RCVD IAC ?
One issue with this is that it is missing characters at the beginning where it should say Log: [*****] BUG:…Another is that it is thinking it got IAC ? even though the IAC MSDP SB function is being called

When in reality I shouldn't get any bug report since debug_telopts is disabled


Did you pull the debug_telopts call out completely from translate_telopts? debug_telopts appears to send a log message even if TELOPT_DEBUG is false.
06 Oct, 2010, Rojan QDel wrote in the 12th comment:
Votes: 0
No, but it should only send a log message if there's an error, which there shouldn't really be.
06 Oct, 2010, Tavish wrote in the 13th comment:
Votes: 0
Rojan QDel said:
No, but it should only send a log message if there's an error

Should and does are different things. debug_telopts sends a log message with every IAC received.
06 Oct, 2010, Rojan QDel wrote in the 14th comment:
Votes: 0
Heh, good observation, I just changed it to only send the ? bug message if srclen == 0, however the issue still exists of the weird memleak.

Any time I send the MSDP request, the next in-band output I get from the MUD is missing the first 8 characters
06 Oct, 2010, Tavish wrote in the 15th comment:
Votes: 0
It could be that you need to update the d->outtop when you copy the new info to your outbuf.
06 Oct, 2010, Rojan QDel wrote in the 16th comment:
Votes: 0
I'm having issues properly doing that, if I update the value of d->outtop I'm getting all sorts of memleaks and if I don't, the same…
07 Oct, 2010, Scandum wrote in the 17th comment:
Votes: 0
translate_telopts() requires an input buffer, the input buffer's length, and an output buffer as arguments. It's alright for the input and output buffer to be the same buffer. translate_telopt() returns the length of the data written to the provided output buffer, which will be equal to the original buffer, or less if telnet data was removed from it.

What wickedmud does is that it reads from the socket straight into the permanent input buffer, then that input buffer is parsed for telnet data, and the input size is updated with the length returned by translate_telopts().

A somewhat more readable method would be:

char temp[MAX_INPUT_LENGTH];

int nRead = read(d->descriptor, temp, MAX_INPUT_LENGTH);

d->intop += translate_telopts(d, temp, nRead, d->inbuf + d->intop);


translate_telopts also strips out \r characters, and I think wickedmud's translate_telopts() also strips out all non printable characters, so the remaining buffer should be pretty easy to parse for commands.
0.0/17