Issue: menu_login still has double enter problem when connect via telnet client such as ZMud

[zero9k]

Win7 x64, Zmud 4.62 menu_login Evennia-beta-git-6ac4375 It happens very often. When I connect to the game via Zmud and enter "1" to login my account, most time I get the prompt to enter the account name and then the welcome and the login menu again. You have to try lots of times to get the right response, like 10% chance. When you luckily get the prompt to enter the name, you still have to enter many times to the next step.

[derringt]

Same issue with powtty client (http://www.elvenrunes.com/powtty/).

[chrzyki]

I'm not yet sure what exactly causes this but I've managed to observe a couple of things which, I hope, might serve as a starting point for the more advanced developers:

• I wasn't able to reproduce this problem with a client running from a Linux machine (Telnet, tinyfugue, tintin).
• With a Windows machine, I can use the menu with PuTTY as a client, PowTTY and zMUD (as described by @zero9k and @derringt) do not work.

This made me want to check how the communication of a) PuTTY with Evennia looks like from Windows and b) how the communication of PowTTY with Evennia looks like from Windows. The results were as follows:

• All menus are, on the packet level, transferred equally (including all the control characters) to the client.
• Sending an option (e.g. '1'), however, leads to different results/responses
  • for PowTTY: 1 is transmitted as plain 55 bytes data package and the server immediately replies with an '\r\n' control sequence and the 'Please enter your account' message, in one and the same 110 bytes package. Immediately afterwards the client sends another '\n' control sequence which triggers the seemingly infinite repetition of the menu (since no account name was specified and the client just gave a blank line).
  • for PuTTY: 1 is transmitted as plain 55 bytes data package and after this the client sends the '\r\n' control sequence to the server (before the server replies and with an additional carriage return). The server responds with an '\r\n' and 'Please enter your account name' and everything works as expected because the client doesn't send any other control characters.

Unfortunately I'm absolutely no expert when it comes to Telnet, control characters, and so on. Maybe it helps to play around with the different LF and CR options the different clients have to offer? It certainly looks like certain clients send additional control characters which break the menu.

[Griatch]

@chrzyki

Interesting, will look at that - thanks for the analysis.

Actually, from looking more at your report, it appears that this is due to a race condition. PowTTY appears to delay to send its carriage return over the wire. Not having fired up wireshark myself at this point I assume this is actually the carriage return that the client made to send the "1" in the first place? If so, it's quite clear - if the carriage return is not sent until in the next package, Evennia has plenty of time to respond to the one and update its state (and even send it back, apparently). And when the client finally decides to send its carriage return it is thus perceived as an input on the new menu node. Sounds very strange at this point.

[chrzyki]

Exactly! The carriage return is actually the one that should have been sent with the '1'.

This is what it looks like for me with the default settings and PowTTY:

And here the same with the default settings and PuTTY:

[Griatch]

Cannot reproduce in Zmud 7.21 (the latest Zmud) on Windows. The menu_login works just fine. Could reproduce it in PowTTY 1.02. Man, this must be one of the least compliant clients I've seen in a while.

The latest push checks for commands coming in without a line break and forces Evennia's telnet protocol to look out for and strip errant line breaks arriving much too late. This resolves the issue mentioned here, both for PowTTY and likely also for older versions of Zmud. Please respond and confirm.

Thanks to chrzyki for the wire analyzis work, sped this up a lot!

It should be noted that with PowTTY I need to start entering the password twice, since PowTTY seems to have the strange notion of interpreting the NOECHO telnet command as also kicking it out of LINEMODE. The result is that it attempts to send the first letter in your password immediately without waiting for a line break. As far as I know this is completely un-standard behavior and since Evennia has not been told to exit LINEMODE (and indeed does not support doing so under telnet), it will react like that first letter is the only letter of your password and give you a "password not recognized" error. You can still enter the password the second time (since at this point the NOECHO mode has been exited). Alas, there is no way to fix this latter issue since PowTTY also does not properly identify itself using TType to Evennia (it just identifies itself as Xterm which is not very helptful). As far as I can tell it is an error in PowTTY's negotiation. And since that client was last updated in 2001 there seems to be little hope of seeing it updated.

[zero9k]

Zmud 4.62 is widely used in China because it's the best version supporting Chinese...- - Test result report: It's better after the update, about 1/3 chance to get the right response. =)

[Griatch]

@zero9k

I would rather think that 4.62 is widely used since it is a free version whereas the newest ones cost money ... 4.62 is what, 10-12 years old now.

If you run wireshark on the connection, do you see the same behavior as chrzyki saw for powtty?

[zero9k]

After this update, the character doesn't quit the game if you close the web client or telnet client.

[zero9k]

@Griatch Cracks for alll versions of Zmud can easily be found all over the web. =) 4.62 is also cracked version. Other versions of Zmud view Chinese characters a little odd. Only this version and Cmud pro has the ordinary view. So most of mud players in China prefer 4.62。 I will download a copy of wireshark and post the test result later

[zero9k]

This the capture result of wireshark, I wish it's useful. Part 1,2,3 is the capture of "double enter"...- - Part 4 is the capture of correct response. 192.168.199.168 is the client's ip, and 188 is the server's.

[Griatch]

@zero9k

Thanks for the wire output. The problem is however that I cannot replicate your problem. I got Zmud 4.62 and connected with the menu_login contrib and ... it works just fine.

I have tested over and over and every step of the login process works 100% under this version of Zmud. There are no double carriage returns. I also see no problems with disconnecting and characters remaining (but this would be a separate issue anyway).

Are you sure you are really using the latest Evennia version? Note that you have to stop and restart the Portal too to see any changes since the patch I did was to the telnet protocol.

[zero9k]

@Griatch

• -! I am sooooooooooo SORRY that I didn't restart the portal( I just use "python evening.py reload"...- -!). I did it just now and the issue is totally solved. The menu_login works just fine now. Really sorry for the haste and idiocy, Causing you so much trouble downloading and testing... T_T 😭 Deepest apology

[Griatch]

No worries, good to hear it was not a more difficult error. For most updates a normal reload works, but for everything related to updating protocols, ANSI etc, the Portal must be restarted as well. Closing this now.