Mudlet or game output hangs with crafted input

[Vadim Peretokin]

Steps to reproduce:

* ensure your command separator is set to ;
* connect to an IRE game like Lusternia.com and log in
* do: lua display((Polaris): You say, "Test.")

What happens: any input you enter is not reflected by the game. Mudlet still sends the input (confirmed by Wireshark) and Mudlet still receives output from the game (confirmed with ambient effects still showing).

It makes it really hard to tell if it's Mudlet or the MUD with the issue since Mudlet is still sending and receiving data as far as I see.

Reported by Pharanyx on Discord.

[Stephen Lyons (slysven)]

Is that an accurate reflection of the EXACT string entered into the command line with (or in this case, WITHOUT) '"' marks? As written there it appears to be four separate "commands":

lua display([

33

44m(Polaris): You say, "Test."[0

37m

One might suspect the odd ASCII 27th character (ESCape) in there but I am assuming nothing!

The first will be picked up by the run-lua-code Alias if it is enabled and it will fail to compile and thus produce a lua error (at least in the Central Debug Console and possibly the "Errors" window in the Editor if it is open/active); but the three remaining things will get sent to the MUD to provoke whatever that would do with them at the time.

It could be that the OP was stuck with how to escape their use of the ';' character when it is registered as a command separate - which could well be an issue!

The simplest "fix" would be (an option?) for the place where the input is split into multiple commands to skip immediately adjacent *identical* separator characters in the typed stream and to remove the second, on the understanding that this will occur anywhere, even within "quoted strings", thoughts anyone?

[Vadim Peretokin (vperetokin)]

Yes, it's an accurate reflection, you copy/paste it as-is. It is indeed something that gets split up into separate commands, that's why command separator being the default is important.

I don't think messing with the command separator is the fix here, the command separator doing it's job is not the issue. The issue is either Mudlet or the game 'hang' on such input provided!

[Stephen Lyons (slysven)]

Well, is there ASCII ESC characters in there or not - they would not be visible in a copy and paste to, say here and they were entered as a literal in a Mudlet Lua code/script in the editor they would not be saved correctly IIRC.

Actually, reading between the lines it is almost as if telnet echo (suboption 1) has been set incorrectly somewhere - IIRC we do not ever allow it to be turned off on our end - which is broken for log files/replays where the server has told us not to echo but we still do and thus stick passwords that we send and then get echoed back stored in the buffer/logs. Given that, is it possible that something in that combination is being interpreted as telling the server NOT to echo what we expect it to?

I may have this totally wrong - I will really have to get my head around telnet option negotiation someday. 8-(

As to being able to mess with the command separator - sometimes you DO need to send the separator character to the MUD - like in this case where it is required for what looks like an ANSI ESC code - so how do we get around that?

[Martin Tee (taernae)]

Sent By: Ianir on 2017-03-23 15:12:13
Greetings. Regarding your ANSI bug, this seems to be at the Rapture level and has been forwarded on to IRE (who will maybe solve it before the entropic death of the universe if we're lucky). If you need colour or newlines in echo, you can use $<FG>[:<BG>]$ to insert colours (based on the COLOURS command) and, as a bonus, $n$ for newlines.

[Vadim Peretokin (vperetokin)]

Thanks! Closing then as a MUD engine bug.