TELOPT_NEW_ENVIRON negotiation issue.

I don't know if it is on my end, or the client's end, but at the login screen of my MUD, it looks like a portion of my response to IAC WILL TELOPT_NEW_ENVIRON is printed as plaintext to the screen in the mudportal client.

My response is: <IAC> <SB> <TELOPT_NEW_ENVIRON> <ENV_SEND> <ENV_VAR> "SYSTEMTYPE" <IAC> <SE>

and it looks like everything after the <ENV_VAR> is printed to the TTY.

Any ideas?

Thanks!

Looks good, thanks!

One more question: for MXP and GMCP, is the client expecting the server to start negotiation with a DO request? We send a WILL for both, and don't seem to be getting a response from the client.

Thanks for looking into it. This morning I noticed a new issue that started to crop up. I'm not sure if it's related to the fact that I am on my ipad right now, or a result of the mxp negotiation, but after the screen fills up, it starts outputting garbage. The easiest way to repro this is to connect to materiamagica.com:23, create an account, and then type "protocol" to see the negotiated protocols. Usually before this point the screen will have filled up , and random characters appear on the screen (it looks like the same area of memory is being repeated/accessed multiple times)

Looks like it's ipad/safari specific. I tried on my PC running Firefox, and everything looks fine. (On the ipad it happens eventually regardless of whether protocol is typed or not - I also disabled the MXP checkbox on the mudportal client, and got the same result, so I think you may be correct about MCCP)

256 color and TTYPE negotiation is currently disabled on the live server, but is working and negotiating fine on the development server with the mudportal client. MXP 0.3 looks to be negotiating okay. (yaay! thanks.)

gmcp still doesn't look to be negotiating correctly (which is actually the out of band protocol I'm most interested in utilizing for custom interface work). I'll have to make another attempt and see what the logs are saying. I've tested GMCP on the server with tintin++ and mushclient and everything is working out with those, but protocol negotiation is such a loose standard, who and how it's initiated can change from client to client.

Thanks again for helping me work through the issues - I think what you are working to do here with the site will really give MUDs a second wind.

Yes, that's another bug that is fixed on the dev server as well (my GMCP hander was only reporting the size of the payload as read to the parser, so a number of bytes equal to the size of the GMCP telopt flags was left in the buffer), but hasn't been pushed to live yet (I've been doing quite a bit of protocol work this past week.)

Everything looks great, now!