Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login to Nanvaent does not display login screen #3530

Closed
mpconley opened this issue Mar 27, 2020 · 11 comments
Closed

Login to Nanvaent does not display login screen #3530

mpconley opened this issue Mar 27, 2020 · 11 comments

Comments

@mpconley
Copy link
Contributor

Brief summary of issue / Description of requested feature:

A Mudlet Discord user bato#3029 reported an issue the week of March 27, 2020 of not being able to login to the game Nanvaent on nanvaent.org port 23. @mpconley aka Tamarindo experienced the same issue on Mudlet 4.6.2 on a Mac, then suggested compression be turned off. This worked initially, but upon a return to Nanvaent to check on another issue the same thing happened for Tamarindo although compression was still off. The connection does get made and there is a message about MXP being negotiated that shows up. This connects OK in TinTin++.

Steps to reproduce the issue:

  1. Create a profile for Nanvaent
  2. Connect to the game
  3. Observe the lack of login text

Please feel free to share in the comments if you have the same experience on your platform.

@atari2600tim
Copy link
Contributor

I tried reconnecting a whole bunch of times in a row, and I got the MXP enabled message and then a short delay and then the login screen with no problem. I did it about 30 times.

Then I closed and restarted mudlet, and now it is only showing the MXP enable message exactly as described. Next I tried the same thing on a different computer, this time just closing the profile, and same thing... second to last try worked, and then reload profile and last time it doesn't work. I saved data that went through (I connected through a proxy to record it), and both sides sent identical data the last time and second to last time.

The last packet from the server looks like a mess on both of the final attempts. But it still looked like a login screen on mudlet on the last try before I reloaded the profile. I think that they negotiate no compression and then the server starts compressing at that point, and maybe mudlet had some reason to understand the compression prior to reloading profile?

@willshattuck
Copy link

I'm getting the same issues being described above but I don't know how to get any more data to you about why it's happening. I found nanvaent through MUDRammer on my phone and wanted to see how it looked on a modern desktop MUD client.

@mpconley
Copy link
Contributor Author

Any Mudlet Core Devs think any of these negotiations would be an issue for Mudlet? I can't see any more setting to disable that could help here.

#config telnet debug
#CONFIG {TELNET} HAS BEEN SET TO {DEBUG}.
#session nan nanvaent.org 23
#TRYING TO CONNECT 'nan' TO 'nanvaent.org' PORT '23'.

#SESSION 'nan' CONNECTED TO 'nanvaent.org' PORT '23'
RCVD IAC DO TERMINAL TYPE
SENT IAC WILL TERMINAL TYPE
RCVD IAC DO NAWS
SENT IAC WILL NAWS
SENT IAC SB NAWS 0 202 0 56
RCVD IAC WILL MCCP2
SENT IAC DO MCCP2
RCVD IAC DO MXP
SENT IAC WONT MXP
RCVD IAC WILL MSSP
SENT IAC DO MSSP
RCVD IAC WILL ZMP
SENT IAC DONT ZMP
RCVD IAC DO NEW-ENVIRON
SENT IAC WILL NEW-ENVIRON
RCVD IAC SB TERMINAL TYPE
SENT IAC SB TTYPE TINTIN++
RCVD IAC SB MCCP2
MCCP2: INITIALIZED
RCVD IAC SB MSSP
RCVD IAC SB MSSP VAR NAME                 VAL Nanvaent
RCVD IAC SB MSSP VAR PLAYERS              VAL 10
RCVD IAC SB MSSP VAR UPTIME               VAL 1588875912
RCVD IAC SB MSSP IAC SE
RCVD IAC SB MCCP1

 [===--------------===] E-mail : nanvaent@nanvaent.org [===--------------===]

                                 /\     
                                /  \                  __
                               / /\ \                /  \
                              / /  \ \               \  /
                             / /    \ \              / /
  ____________ ____  _____  /_/_  ___\ \ ____  _____/ /____________ _________
 (___________ /    \ \___ \/    \/  \ \ \___ \/  _  \/    \__   __/__________)
     (________\  \  \/  _  \  \  \   \ \/  _  \  ___/\  \  \ \  \ _______)
         (_____\__\_/\_____/\__\_/\____/\_____/\____/ \__\_/  \_/____)
                        / /              \ \    / /
                       / /                \ \  / /
  Use 'guest' if      /  \                 \ \/ / 
  you just want to    \__/                  \  /  
  look around.                               \/   

   telnet nanvaent.org                                  http://nanvaent.org/
 [===--------------===] E-mail : nanvaent@nanvaent.org [===--------------===]

Your rights may be disclaimed. Please type "help rights" after login.
PLEASE use the 'bug' command to log bugs you find.

@vadi2
Copy link
Member

vadi2 commented May 28, 2020

@SlySven mentioned he'd be able to look at this.

@SlySven
Copy link
Member

SlySven commented May 30, 2020

I have managed to get in (as a guest) by:

  • disabling MCCP1/2 ("Force Compression off" option)
  • disabling MXP ("Force MXP negotiation off" option) doesn't seem to be the problem
  • disabling GA ("Force telnet GA signal interpretation off" option) doesn't seem to be needed
  • expecting only LineFeeds ("Strict UNIX line endings") doesn't seem to be needed

MSDP and GMCP were enabled though only the former was negotiated and presumably used.

  • BTW the debug messages in that case include:
Server sent telnet IAC DO TTYPE (24)
We ARE willing to enable telnet option TERMINAL_TYPE
WE send telnet IAC WILL TTYPE (24)
Server sent telnet IAC DO NAWS (31)
We ARE willing to enable telnet option NAWS
WE send telnet IAC WILL NAWS (31)
Server sent telnet IAC WILL MCCP2 (86)
WE send telnet IAC DONT MCCP2 (86)
Rejecting MCCP v1, because v2 has already been negotiated or FORCE COMPRESSION OFF is set to ON.
Server sent telnet IAC DO MXP (91)
We are NOT WILLING to enable this telnet option.
WE send telnet IAC WONT MXP (91)
Server sent telnet IAC WILL MSSP (70)
WE send telnet IAC DO MSSP (70)
MSSP enabled
Server sent telnet IAC WILL ZENITH (93)
WE send telnet IAC DONT ZENITH (93)
Server sent telnet IAC DO NEW_ENVIRONMENT_OPTION (39)
We are NOT WILLING to enable this telnet option.
WE send telnet IAC WONT NEW_ENVIRONMENT_OPTION (39)
Server sent telnet IAC WILL MCCP (85)
WE send telnet IAC DONT MCCP (85)
Rejecting MCCP v1, because v2 has already been negotiated or FORCE COMPRESSION OFF is set to ON.
MCCP version 1 starting sequence

So that first rejection message is wrong...

In game you will want to issue the commands termdetect off and term xterm as it does not seem to recognise Mudlet xxx as a client it knows about and the dumb default is pretty much devoid of any colour/formatting. Also, an examination of the who list when I was there indicates that they use UTF-8 as their server encoding (One of the players there had inserted a U+202E {Right-to-Left Override} in an attempt to have their name written backwards - but since Mudlet is not (yet) capable of BiDi text display it just showed the text the way it was written - though my text analyser did report it's presence in the text even though the paint code just choked on it).

Interestingly they do make use of flashing (blinking) mode so Vadim's hack to make that appear ITALIC shows up there...

So it does seem that the MCCP2 negotiation is failing - and that I am going to have to get up close and personal with some bytes that I stored in a recording of that process and see if I can make out what is going on...

@jhersh
Copy link

jhersh commented May 30, 2020

Also related to MCCPv1 in Nanvaent: #3056

@willshattuck
Copy link

This:
disabling MCCP1/2 ("Force Compression off" option)
worked for me. Thanks. I didn't know what to even do to test.

@SlySven
Copy link
Member

SlySven commented Jun 2, 2020

I have a replay of Mudlet not accepting the MCCP2 startup sequence and I have decoded the bytes in the recording up to the point where MCCP2 is supposed to be started:

"ÿý�" = 255 253 024
IAC DO TTYPE

"ÿý�ÿûVÿý[ÿûFÿû]ÿý'" = 255 253 031   255 251 086   255 253 091   255 251 070   255 251 093   255 253 039
IAC DO NAWS IAC WILL MCCP2 IAC DO MXP IAC WILL MSSP IAC WILL ZMP IAC DO NEWENV

"ÿú��ÿð" = 255 250 024 001 255 240
IAC SB TTYPE SEND IAC SE

"ÿúVÿðxÚúÿË" = 255 250 086 255 240 | .....
IAC SB MCCP2 IAC SE | ...

However, when replying it (in a temporary version of the current development branch that pre-stored all the replay data chunks) I noticed that the MCCP1/2 activation code (the decoded bytes of the last line) was not being hit in the debugger. So I will be taking a closer look at the execution path whilst replying the above.... 🔎

@SlySven
Copy link
Member

SlySven commented Jun 3, 2020

Well that is just plain weird - with MCCP 2 (or presumably 1) enabled - data is being sent to Mudlet as it should - but it is never making it as far as the screen! - yet presumably it is working for other MUDs otherwise there would be much screaming and gnashing of teeth amongst all our users!

@willshattuck
Copy link

FYI, I am no longer able to connect to nanvaent.org using any combination of the settings above. Not sure what's going on.

@SlySven
Copy link
Member

SlySven commented Jul 11, 2021

Trying with current development branch code I was able to connect:

  • with MCCP2 enabled and MXP disabled
  • with MCCP2 disabled and MXP enabled

finally I tried this

  • with MCCP2 enabled and MXP enabled

and that worked as well:

image

So it seems the problem may have gone away...

🙄

@vadi2 vadi2 closed this as completed Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants