Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ MUSHClient locking up after sending
MUSHClient locking up after sending
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Highsorcerer
(4 posts) Bio
|
Date
| Thu 27 Aug 2020 07:54 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #1 on Thu 27 Aug 2020 09:20 PM (UTC) |
Message
|
|
Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.
|
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Highsorcerer
(4 posts) Bio
|
Date
| Reply #2 on Fri 28 Aug 2020 12:29 AM (UTC) |
Message
| I am using version 5.06 of MUSHClient. | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #3 on Fri 28 Aug 2020 06:22 AM (UTC) |
Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #4 on Fri 28 Aug 2020 06:26 AM (UTC) |
Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Highsorcerer
(4 posts) Bio
|
Date
| Reply #5 on Fri 28 Aug 2020 06:27 AM (UTC) |
Message
| I'll try it out. Is that an installer or just the exe I should drop in the folder where 5.06 is? | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #6 on Fri 28 Aug 2020 08:38 AM (UTC) |
Message
| It's an exe. The instructions I linked state that you copy that over the existing exe in the installation folder you already have. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #7 on Fri 28 Aug 2020 08:53 AM (UTC) |
Message
| What can cause this is incorrect telnet subnegotiation by the server. In particular, MUSHclient is designed to allow for:
IAC SB .... (a lot of stuff) ... IAC SE
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).
Quote:
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()).
This tends to suggest it is a server issue. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #8 on Fri 28 Aug 2020 01:52 PM (UTC) |
Message
|
Quote: which is IAC SB (start of IAC - interpret as command - subnegotiation) and doesn't terminate it
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? |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #9 on Fri 28 Aug 2020 09:12 PM (UTC) |
Message
| 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:
The packet debug, if supplied, could help us assist in doing that.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Highsorcerer
(4 posts) Bio
|
Date
| Reply #10 on Sat 29 Aug 2020 01:08 AM (UTC) |
Message
| 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! | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
24,005 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top