When a server requests that MUSHclient suppress go-ahead signals (IAC DO SUPPRESS-GO-AHEAD), MUSHclient 3.42 grants the request (IAC WILL SUPPRESS-GO-AHEAD) even if it's already in that mode. This can lead to endless option negotiation loops.
Here's the relevant paragraph from the Telnet Protocol Specification (http://www.faqs.org/rfcs/rfc854.html):
Here's the relevant paragraph from the Telnet Protocol Specification (http://www.faqs.org/rfcs/rfc854.html):
Quote:
If a party receives what appears to be a request to enter some mode it is already in, the request should not be acknowledged. This non-response is essential to prevent endless loops in the negotiation. It is required that a response be sent to requests for a change of mode -- even if the mode is not changed.
If a party receives what appears to be a request to enter some mode it is already in, the request should not be acknowledged. This non-response is essential to prevent endless loops in the negotiation. It is required that a response be sent to requests for a change of mode -- even if the mode is not changed.