Protocol Negotiation Issues

On the wilderness map of Luminari MUD, we currently use background colors in some areas. While this may change, I did notice that the mud client shows TWO characters, a 'm' and the character I expect to see. This sends the whole map out of alignment, screwing up navigation and pretty much everything.

Thanks!

- Ornir Elunari

The quickest way to reproduce the issue is to log in when I am around!

The wilderness is still in development and there is no easy way to get there from the mud proper.

- Ornir Elunari

Seeing the same issue on Wayfar - quickest way to the map is to create character, head east after leaving the shuttle, set gender, choose background, then CHOOSE DISPATCH, pick a planet, and you'll be landed in the wilderness.

That might be how Wayfar specifies background ANSI as well, I'll have to check. Map display is improved by a lot, although it's not coming through exactly as displayed in MushClient:



One other thing I've noticed:

#-5457 from (mudportal websocket proxy) > client mudportal.comclient_version 1.0client_ip 63.233.133.4E[**Vco swampdog ******

This first line sent by the web client is not terminated with a newline, so the first time you try to login (co swampdog *****) the client identifier line is all jumbled up with your login and the login fails.

that change has made the 256 colors stop working entirely on my test mud!! And my main mud also!!!

connect to godwars.net 2770, and type help extended colours....
using the portal app...

or just type colorlist ( i think thats the command.... not really been working on that code) the greeting should be in orange... and if you check "finger" it no longer displays the Protocols you are supporting... nor the client you are using to connect (but this all works when connecting via mushclient)

still not working...

looks as if the actual protocols are not being negotiated by the mudportal plugin, used to work... Issues affecting my test mud.. AND Legends of Hatred....

its not showing any protocols... nor is it showing the name of the client...

will point out that the negotiation works on zMUD, cMUD and Mushclient... just hasnt since the first response on this thread by me (if that gives you a little idea as to when the issue started)

if you connect to my mud.. and type finger (on your own character) it should show the following if protocols are supported:

Client: MUSHclient (Version: 4.91).
Protocols: NAWS, TTYPE, 256 Colours, MXP (0.5), MCCP.
Screen Size: 271 characters wide and 60 characters high.

LoH and the test mud use a modified version of KaVir's MUD protocol snippet, just attempted to connect to a MUD that uses an unmodified version of that code, and it hangs on connection.. so my guess is its something your end... not on the MUD's concerned...

never get past password entry screen...

I don't see the mudp client doing any linemode, naws, ttype or env negotiation when it connects. LO sends these modes to the client:

IAC WILL TELOPT_ECHO,
IAC WILL TELOPT_SGA,
IAC DO TELOPT_TTYPE,
IAC DO TELOPT_NAWS,
IAC DO TELOPT_NEW_ENVIRON,
IAC WILL TELOPT_MSSP,

And all it gets back from the client is:

IAC WILL 201
IAC DO 69
IAC DO 86

(LO doesn't support those protos and they aren't in arpa/telnet.h so I don't have a decode for what they are.)

Works now... BUT no longer displays the client name.. displays it as "unknown" used to (before all the changes back at the start of the thread) display "Mudportal Client" or something along those lines... doesnt also appear to be negotiating 256 colours at al now!!

that got it... its working exactly like it was before the changes to the code back at the start of this thread.. thanks for looking into it.. i was wondering if it was my mud that was at fault..

Now on input I'm seeing:

IAC WILL 201
IAC WILL 91
IAC WILL TTYPE
IAC SB TTYPE IS mudportal.com IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS XTERM-256color IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS MTTS 141 IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS 69.181.111.151 IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS 69.181.111.151 IAC SE
IAC DO 86

Im still not seeing NAWS or ECHO or SGA negotiation. Should I be?

LO only asks for a TTYPE with a SEND when it gets a WILL TTYPE, and it won't ask for more than one ttype, so I suspect you are sending the WILL TTYPE's gratuitously after sending a TTYPE value instead of waiting for the next request from the server. Is that what is going on? My game can certainly deal with that, but for compatibility, RFC 1091 section 5 says that "Terminal type information may not be sent spontaneously, but only in response to a request."

In Mud Terminal Type Standard , the section on proxies suggests sending the IP address as a NEW-ENVIRON variable named IPADDRESS, rather than appending it as another ttype value. I think that recommendation is a lot easier to parse on the server, and its already how I've implemented address reporting for the LO proxy. Would be cool if mudportal did it that way.

I'm totally going to implement full mtts on the LO server if the mudportal client is using it. Very cool, plamzi.

Sorry man, I should have been more clear. What I meant in my previous post was: "I do not see the client explicitly refusing the server's offer to ECHO and SGA. Did you intend to have the client ignore the offer, or did you intend to refuse it with a DONT? Either way is correct- but I'm not seeing an explicit DONT"

When a server sends WILL ECHO and WILL SGA to a client, the is server trying to tell the client that it can support char-at-a-time mode-- like the mode what happens with a typical telnet or ssh cli shell session. In that mode, user types a character, and the client sends it immediately to the server without displaying it to the user. The server receives the character and decides whether to send it back to the client for display to the user. The server gets every keystroke and completely controls what is displayed back to the user.

Like a lot of (most?) mud servers, the mudportal client operates in a line-at-a-time mode. User enters a line of text, the client takes care of the line editing and character printing, and a complete line is sent up to the server only when the user hits enter. The server isn't supposed to echo the line back to the client for printing, because the client has already taken care of it.

My understanding is that when a server offers to provide ECHO and SGA by sending a WILL for those options, a client like mudportal that wants to stay in line-at-a-time mode has two options- either don't respond at all to either offer because line-at-a-time is supposed to be the default behavior, or respond with a DONT to explicitly refuse the offers.

Having the client respond with a DO ECHO isn't right, because the client has already shown the input line to the user. The server shouldn't try to do it too.


Setting the IPADDRESS variable via NEW-ENVIRON looks like it is working great on my end!

Thanks for the explanation on the TTYPE behavior. I understand now why you are doing it that way, and I'll fix my server side code to be more tolerant.

On NAWS- Its not useless. Muds that support the option use it to determine how many lines to display before sending the "hit return to continue" message in a pager, and some muds use it to decide when to wrap text. For example, LO uses it to decide how big of an ascii graphic map it can send to the user when they ask for one. LO and stock dikumuds default to an 80x24 size when there's no negotiation, so its not a big deal if the client doesn't support NAWS- but it means that paged text has a 'hit return' prompt after every 22 lines. Even if you don't ever want to support vt100 cursor positioning commands, it'd be a nice option to include in the client.

Ok, option negotiation looks good to me. Sweet!

On the NAWS subject- I get what you are trying to do. I'm just saying that as nothing more than a concession to compatibility, It might be a useful thing to negotiate the window size to get the server side pager prompts and line wrapping to happen more reasonably. At least it would be there as a fallback until game devs can utilize the cooler browser functionality.

As a server developer I don't think NAWS is useless, but if its low on the priority list for the client code, so be it.

Hate to say this Plamzi.. but what ever you have done to the mud portal app recently has made background colors no longer show on my mud... nor protocols getting negotiated properly (my mud MAY be down sporadicly... we have some issues we are working though)

I will just say that before the changes you made mudportal app was working fine... apart from being sent random characters when it was negotiating the protocols on connection.

ok then... i take that back.. sorry.. lol... you mustve been mid change when i checked!!

Looks like my TTYPE is showing the IP address since it repeats itself twice. We switched over to use Kavir's protocol snippet, so I can only assume that everyone using it will be seeing the same thing? Looks like everything else is showing up correctly. Any ideas or should we simple capture the first TTYPE given which is actually against the RFC protocol as its supposed to repeat itself?


I am attaching a screenshot of my display.

I was looking over the connection data for one of my players who uses the client here and see something strange with the MTTS PROXY IPADDRESS reporting.

Plamzi, instead of setting the environment variable named {IPADDRESS} to {1.2.3.4}, the client is setting variable { "IPADDRESS" } to { "1.2.3.4" }. Both the variable name and its value are being sent with a surrounding double quote and space. I don't think its supposed to be that way. The quotes and spaces aren't supposed to be sent by the client, are they?

You should lose the spaces too. It was sending the 13 byte variable name {_"IPADDRESS"_}. After you removed the quotes it sends the 11 bytes {_IPADDRESS_}. It should send the nine byte name {IPADDRESS}. I've replaced spaces with _'s to make them stand out.

I agree with you on the RFC. Might have been clear as a bell in 1983, but today it's just confusing.

Beauty. Lookin' great.

Terminal: mudportal.com (80 x 25) (noecho/nosga)
Full TTYPE: mudportal.com, XTERM-256color, MTTS 141, 69.xxx.xxx.151
MTTS Decode: ANSI, UTF-8, 256 COLORS, PROXY
IPADDRESS = 69.xxx.xxx.151