MUSHClient locking up after sending

So, I'm having pretty much the same problem as posted here:
http://www.gammon.com.au/forum/?id=14338

I want to go into a little more detail with it because I noticed it usually only happens -immediately- after I send something to the world, which to me does not make sense for the router to be closing that connection within seconds of it sending and receiving data.

Setting up a timer does not fix the problem. It happens intermittently and, usually, within a few seconds of my client sending something to the world.

I've noticed it only happens on the server I'm connected to running PennMUSH version 1.8.6 patchlevel 1 [12/XX/2016] (rev 4898921) (as per version())

It does not happen on the other server I connect to running MUX 2.12.0.4 #16 (again, as per version()).

It's confusing because it happens right after I send something to the world, which excludes the idea of it closing the connection because it's idle. It's also confusing because it only happens on the one running PennMUSH and not the one running MUX. It's further confusing because I seem to be the only one experiencing this problem. I don't know if this is something worth looking into or not, but the bug report forum here is the -only- place I've seen it mentioned and, frankly, I am at a loss for how I might fix it and I would really appreciate some help.

I am using version 5.06 of MUSHClient.

I have a feeling that there was some change fairly recently that might account for (fixing) that. However I can't see a reference to it in the release notes.

In any case, try the latest pre-release version as described here:

http://www.gammon.com.au/forum/?id=13903

I don't think it can do any harm.

I have a vague feeling it is something to do with MXP. (Bear in mind I have never reproduced this myself).

Try disabling MXP and see if the problem goes away (assuming it is enabled).

World configuration -> Appearance -> MXP/Pueblo -> Use MXP/Pueblo -> never.

I'll try it out. Is that an installer or just the exe I should drop in the folder where 5.06 is?

It's an exe. The instructions I linked state that you copy that over the existing exe in the installation folder you already have.

What can cause this is incorrect telnet subnegotiation by the server. In particular, MUSHclient is designed to allow for:



Now if the server sends:




... which is IAC SB (start of IAC - interpret as command - subnegotiation) and doesn't terminate it then MUSHclient will "swallow" all of that, waiting for the IAC SE.

You could try turning on packet debug (Edit menu -> Debug packets) and see if the packets are actually arriving (which lets your router off the hook).

If you can reproduce this reliably, then turn on packet debug before it happens and post the problem packet(s).



This tends to suggest it is a server issue.

I know that it would be technically wrong, but for MUSHclient's purposes how bad would it be to stop waiting at the next packet?

It’s not really waiting. It is getting data (in this hypothetical scenario). It’s just that it thinks (if code can think) that it is in the middle of an IAC SB … IAC SE sequence.

I don’t think you can arbitrarily decide to cut that sequence short. It is designed to not have a (maximum) length deliberately so you could conceivably send a large map, or something like that (eg. help information) which might take multiple packets.

Also, even if you timed out, or had a maximum length, the underlying problem would still be there. The next time the server sent this sequence you would lose some, at least, of what you should not lose.

If the OP can identify some sequence that this particular server sends erroneously they could:

• Get the server coders to fix it; or

• Implement a plugin that detects this sequence and corrects or omits it.

The packet debug, if supplied, could help us assist in doing that.

I've been using the prerelease all day and I haven't been experiencing the issue. I've also been monitoring the debug packets in case it shows up but since it hasn't I expect it's not going to. Either way I'll keep an eye on it for a couple days more and I'll notify you if it happens again and what the packets involved were. Thanks for your help!