-
-
Notifications
You must be signed in to change notification settings - Fork 247
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
Comments
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? |
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. |
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.
|
@SlySven mentioned he'd be able to look at this. |
I have managed to get in (as a guest) by:
MSDP and GMCP were enabled though only the former was negotiated and presumably used.
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 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... |
Also related to MCCPv1 in Nanvaent: #3056 |
This: |
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:
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.... 🔎 |
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! |
FYI, I am no longer able to connect to nanvaent.org using any combination of the settings above. Not sure what's going on. |
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:
Please feel free to share in the comments if you have the same experience on your platform.
The text was updated successfully, but these errors were encountered: