I didn't really understand telnet negotiation when MSSP was discussed originally, but I've been playing around with it recently and thought I might as well get some practice by adding the telnet version of MSSP.

What I was hoping for was something like this:
*** CLIENT CONNECTS ***
CLIENT: Do you provide MSSP data? (IAC DO MSSP)
SERVER: Yes, I will send you a feature list if you want it. (IAC WILL MSSP)
CLIENT: Great! Please send it over. (IAC SB MSSP SEND IAC SE)
SERVER: Here goes… (IAC SB MSSP MSSP_VAR "PLAYERS" MSSP_VAL "52" IAC SE)
But it looks like the server has to initiate it, like this:
*** CLIENT CONNECTS ***
SERVER: By the way, I will send MSSP data if you want it. (IAC WILL MSSP)
CLIENT: Yes, I'd like you to do that. (IAC DO MSSP)
SERVER: Here goes… (IAC SB MSSP MSSP_VAR "PLAYERS" MSSP_VAL "52" IAC SE)
Which brings me back to the old problem of:
*** CLIENT CONNECTS ***
SERVER: By the way, I will send MSSP data if you want it. (IAC WILL MSSP)
CLIENT: Hey, negotiation! Right then, ECHO OFF.
SERVER: Oh poo, sorry. I didn't realise you were using windows telnet.
Have I understood this correctly? Is there some reason why mud clients can't initiate negotiation when they first connect?

I used tintin's "#config {debug telnet} on" mode, and MSSP is indeed sending the data correctly…but only after the player has logged on. Which is pretty useless for crawlers, really. Oh well, I still support text mode.

The downside of text mode is that the crawler goes around hammering "MSSP-PLAINTEXT" if the server doesn't send IAC WILL MSSP in a timely fashion.

Regardless, you can't really send IAC DO MSSP as some servers will interpret this as a user command. If there is no response and you follow it up with "MSSP-PLAINTEXT" some servers might see this as IAC DO MSSP "MSSP-PLAINTEXT" and ignore it as garbage, even when they support text mode. I'm quite sure this'll be the case on SmaugFUSS servers. As far as I can predict it'd be a total mess.

PuTTY has a setting where it goes ahead and starts telnet negotiations, which gives login problems on non telnet capable MUD servers, so the only case where you can justify the client starting telnet negotiations is when connecting to port 23, which is the assigned telnet port as per the Internet standard.

For those not yet aware of the solution, use NEW-ENVIRON to detect Windows telnet and start echoing back what the user types, you can look at the Lola codebase for an actual implementation, not sure if there are others.

Wait, this is a problem and sending "MSSP-PLAINTEXT" isn't?


Well, fortunately for us all, SmaugFUSS is pretty easy to fix in this regard…

I think the potential problem is if you want to do both.

But I'm not sure if this really would be a problem. Even if the characters were treated as garbage, you should just be able to send the "MSSP-REQUEST" on a new line. The crawler would receive some comment like "Illegal name, try another" but that would be before the MSSP data and would therefore be ignored.

I think it would be worth seeing if this really does cause a problem, and if so, just how common it is. It would be really nice if mud clients could initiate negotiation with the mud.

Is there a strong reason not to? Perhaps we could add this as a "best practice" at MudStandards so that competent clients (i.e. not telnet) can reliably identify themselves by initiating their own negotiation rather than depending on server-initiated negotiation, which has all the issues we've discussed.

I like how you can sling shit without any proof. Especially given that MSSP has been running on MW for as long as the MSSP stuff has been in the FUSS bases, and it uses the plaintext version and no issues have ever arisen. If you have proof to back up your claim that the plain text implementation that we use on SmaugFUSS is going to cause issues, I'm all ears. But if this ends up being another of your rants about how subnegotiation is better, you can kindly keep it to yourself, because I'm sick of your preaching on the subject.

Why does the server initiate the handshaking? That is a guaranteed way to break clients which don't support telnet properly. If the client supports it, why not let it do the first handshake with the server assuming lack of support if nothing ever show up?

Personally I would really like that, but I suspect many client developers would balk at the idea of disrupting the player's experience - if the mud tells you "Illegal name, try another" the first time you connect, it's going to look "buggy" to the player.

I think it's a also server/client developer perspective thing. Zugg might feel that old clients should "die", but suggest the same thing about old muds and I suspect you'd get a very different response.

On the other hand, MUSHclient does allow you to automatically activate MXP, which (as we saw in a previous thread) can disrupt your experience on muds that don't support it. I don't see why this couldn't be handled in a similar way.

Then I could configure a version of MUSHclient and make it available for download from my website, and anyone using it would initiate negotiation when they connected. People using that client to connect to older muds might run into problems, but (1) that's not my concern, and (2) they could still switch the option off. It wouldn't really be much different to Aardwolf providing MUSHclient with Aardwolf-specific plugins pre-enabled.

At the end of the day, someone has to initiate negotiation, and whichever side does it runs the risk of encountering a non-compliant partner.

That is a good point. But don't most servers strip out unprintable characters from input? Perhaps that could be a fortuitous accident for us: they'll see the subneg, strip out the unprintable characters, and move on. (Unless of course the negotiation code happens to be a printable character, in which case we're back at square 1.) But: if we made sure that all three characters were unprintable, it might work…

What an utterly nasty problem.
How truly important is it to work around telnet like this? Especially as it's not even installed by default on new Windows OSs…

That could work - I'm pretty sure it would work for Diku derivatives, at least, and I'd be surprised if it didn't work for other muds. It'd be worth testing I think.

Another option might be for the mud to have a specific sequence of escape codes on its login screen to indicate a willingness to accept negotiation, but that seems pretty hacky.


To be fair, I don't think most muds care about it - its common to switch off echo when entering a password, and that would be a one-way switch for windows telnet.

But I do have a few active players who use it on occasion, so personally I'd rather use a workaround if possible. Fortunately telnet MSSP isn't necessary, as there's the plaintext version - but it could be that future protocols require activation prior to login as well.

Mud client developers would probably balk at initiating negotiating first. The answer is because most mud servers are broken.
If we're talking best practices here, depending on which end you sit at, it's probably not a best practice for a client developer to alienate
several hundred muds who can't handle a Telnet negotiation. Even your very polished "commercial/official" telnet clients won't initiate negotiations outside of port 22/23.

Yes. That is exactly what we were talking about. That is why we were talking about ways to try working around many servers being broken.

The solution has already been provided, but please keep at it.

I'm running with the assumption that a lot of smart people have seen this "solution", and have concluded that it doesn't actually work as well as you say it does. Either that or the whole world is simply ignoring you. Pick your poison. :wink:

Another thing I've noticed: When supporting telnet MSSP and using my cygwin client, I get the 'F' character (value 70, i.e., the 'MSSP' character) added before the first command I type. I know MXP sends something similar, and I imagine other protocols will be the same, so this isn't a criticism of MSSP - but I noticed it while playing with MSSP, which is why I'm mentioning it here.

This doesn't happen with GMud any more, as I used donky's idea to negotiate for TTYPE before anything else - GMud doesn't respond, so the mud doesn't send anything else. But my cygwin client responds to TTYPE with "cygwin", so the mud tries to negotiate for the rest.

This isn't too bad, but it's still irritating, and it may be that other clients have the same problem.

I think I vaguely recall some talk about a protocol for returning supported mud protocols, but I don't know if it was just a random idea mentioned in passing or something that's in the works - does anyone know anything about this? If such a protocol sent only unprintable characters then I could use this alongside the TTYPE check.

The other option would be to produce a hardcoded list of supported features for each TTYPE, but that's a pretty damn ugly solution.

Guess you could let the author know that his client's telnet support is broken. It's odd though that the client would only respond with the F character, possibly it's something in your mud's parser that's missing something? Like the client responding with IAC WONT MSSP rather than IAC DONT MSSP.


Isn't that what TELNET is for? You fire a bunch of TELOPTs at the client and it'll respond if you're lucky. There's this tendency in the MUD community to reinvent the wheel, and the sad truth is that if we come up with a new protocol several people will not get it right. Look at my MSSP crawler for examples, about 25% of the MUDs report invalid data, and it'd be 75% if it wasn't for me taking the time to point out any errors.

I think the current situation is pretty decent with most of the popular clients getting it right.

Like what?

Gah, you're right, sorry - I'd forgotten to check for IAC DONT MSSP, and just hadn't noticed before because I'd been testing with TinTin++.

I was thinking this was an extension of the GMud problem (which does display junk characters), but if that's not the case then a list of supported protocols shouldn't be necessary.