I have Mushclient 4.75 on Windows 7 x64, and have been trying to add TTYPE negotiation to my mud. I have it working on intial login, and was then trying to have the mud re-enable it after disabling it right before doing a copyover. So far, it's not working. Through testing via mud debug output, I find that on copyover, Mushclient is still sending WONT in reply to it's DO. Even multiple DO requests go unanswered. On first login, I can disable/enable it in that order just fine, but not on copyover. Mushclient just continues to send WONT only once then.
Let me know if you need any more information about this.
As I recall, MUSHclient only responds once to a TTYPE negotiation (and others) in order to avoid a "negotiation loop". Notice that here:
http://www.faqs.org/rfcs/rfc1143.html
Quote:
Implementors of TELNET should read the examples of option negotiation loops and beware that preventing such loops is a nontrivial task.
If I may suggest, on a copyover, since you have retained all sorts of information about the client (eg. what character it is) why not retain the terminal type?
Well, then it's still weird. I can tell it DON'T first, and then DO, and it will respond with the terminal type.
I knew I could save the type to the copy over file, but I was renegotiating several other protocols any way, and did not want to have to store all that information for that quick a time.
Other clients I've tested with will disable and then reenable terminal type negotiation, they just won't respond to multiple requests of the same type, like multiple DOs.
Nick is right, you need to save it. Not all clients will allow you to renegotiate it, and some use a cyclic TTYPE, so they'd report a different terminal type each time you did a copyover.
Storing the TTYPE in the pfile also makes it easier to collect and monitor client usage stats.
Hmm, I thought by telling the client to disable it, it would reset the cyclic check back to the start, and then after the copy over it would re-enable terminal type and act just like a new connection. I'm doing the cyclic checking now (using bits of your protocol snippet actually), so I go through them all already.
I know Linux terminal client does the disable and reenable just fine, I can check others and get more exact results. Saving to the pfile won't help on copyovers, though might be something nice to have as well.
As far as I can tell, you're correct. When you disable an option, it should reset its state. Of course, MUSHclient might not be the only (or the worst) offender, considering we're talking about MUDs.
Could you please enable the debug packet data (Edit -> Debug Packets), run your negotiations, and paste the output from that new window? (If you don't see a new window, make sure your world's window isn't maximized - it comes up in a MUSHclient notepad.) Note that this contains all data sent and received, so try not to include passwords or anything :)
Ok, here's the output. It's from after I'm logged on, and just issuing a copyover statement to the mud. Mud side, debug output is still turned on, so there's strings like "TTYPE DO SENT" coming from the mud, letting me know it hit that section of code.
Sent packet: 18 (10 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
copyover.. 63 6f 70 79 6f 76 65 72 0d 0a
Incoming packet: 15 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿþ. ff fe 18
Sent packet: 19 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿü. ff fc 18
Incoming packet: 16 (87 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿþ.ÿþ*ÿüEÿüFÿþÈÿ ff fe 1f ff fe 2a ff fc 45 ff fc 46 ff fe c8 ff
üZÿþ[ÿüUÿüV..The fc 5a ff fe 5b ff fc 55 ff fc 56 0a 0d 54 68 65
world suddenly 20 77 6f 72 6c 64 20 73 75 64 64 65 6e 6c 79 20
becomes very tir 62 65 63 6f 6d 65 73 20 76 65 72 79 20 74 69 72
ed and needs a n 65 64 20 61 6e 64 20 6e 65 65 64 73 20 61 20 6e
ap..... 61 70 2e 2e 2e 0a 0d
Sent packet: 20 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿü. ff fc 1f
Sent packet: 21 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿü* ff fc 2a
Sent packet: 22 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿüÈ ff fc c8
Sent packet: 23 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿü[ ff fc 5b
Sent packet: 24 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿþU ff fe 55
Sent packet: 25 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿþV ff fe 56
Incoming packet: 16 (0 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
Incoming packet: 17 (66 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
..The world drif 0a 0d 54 68 65 20 77 6f 72 6c 64 20 64 72 69 66
ts off to sleep. 74 73 20 6f 66 66 20 74 6f 20 73 6c 65 65 70 2e
NOBODY DO ANYTH 20 4e 4f 42 4f 44 59 20 44 4f 20 41 4e 59 54 48
ING TO WAKE IT!! 49 4e 47 20 54 4f 20 57 41 4b 45 20 49 54 21 21
.. 0a 0d
Incoming packet: 18 (534 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
..The world has 0a 0d 54 68 65 20 77 6f 72 6c 64 20 68 61 73 20
awoken from its 61 77 6f 6b 65 6e 20 66 72 6f 6d 20 69 74 73 20
nap, feeling rei 6e 61 70 2c 20 66 65 65 6c 69 6e 67 20 72 65 69
nvigorated. YOU 6e 76 69 67 6f 72 61 74 65 64 2e 20 20 59 4f 55
MAY NOW RESUME 20 4d 41 59 20 4e 4f 57 20 52 45 53 55 4d 45 20
PLAYING!..ÿý.TTY 50 4c 41 59 49 4e 47 21 0a 0d ff fd 18 54 54 59
PE DO SentTTYPE 50 45 20 44 4f 20 53 65 6e 74 54 54 59 50 45 20
Request RecvTTYP 52 65 71 75 65 73 74 20 52 65 63 76 54 54 59 50
E WONT Recvÿý.ÿý 45 20 57 4f 4e 54 20 52 65 63 76 ff fd 1f ff fd
*ÿûEÿûFÿýÈÿûZÿý[ 2a ff fb 45 ff fb 46 ff fd c8 ff fb 5a ff fd 5b
ÿûUÿûV...[1;30mR ff fb 55 ff fb 56 0a 0d 1b 5b 31 3b 33 30 6d 52
une .[1;37mWorkr 75 6e 65 20 1b 5b 31 3b 33 37 6d 57 6f 72 6b 72
oom.[1;37m.[0m . 6f 6f 6d 1b 5b 31 3b 33 37 6d 1b 5b 30 6d 20 1b
[1;36m[.[1;37m16 5b 31 3b 33 36 6d 5b 1b 5b 31 3b 33 37 6d 31 36
88.[1;36m].[1;37 38 38 1b 5b 31 3b 33 36 6d 5d 1b 5b 31 3b 33 37
m.[0m.[1;37m.[0m 6d 1b 5b 30 6d 1b 5b 31 3b 33 37 6d 1b 5b 30 6d
...[0m[Exits: .[ 0a 0d 1b 5b 30 6d 5b 45 78 69 74 73 3a 20 1b 5b
1;33mwest.[1;37m 31 3b 33 33 6d 77 65 73 74 1b 5b 31 3b 33 37 6d
.[0m].[1;37m.[0m 1b 5b 30 6d 5d 1b 5b 31 3b 33 37 6d 1b 5b 30 6d
...[0m.[0m.[1;37 0a 0d 1b 5b 30 6d 1b 5b 30 6d 1b 5b 31 3b 33 37
mA dusty old .[1 6d 41 20 64 75 73 74 79 20 6f 6c 64 20 1b 5b 31
;30mmachine .[1; 3b 33 30 6d 6d 61 63 68 69 6e 65 20 1b 5b 31 3b
37msits here..[1 33 37 6d 73 69 74 73 20 68 65 72 65 2e 1b 5b 31
;37m.[0m.[0m.[1; 3b 33 37 6d 1b 5b 30 6d 1b 5b 30 6d 1b 5b 31 3b
37m.[0m...[0m.[1 33 37 6d 1b 5b 30 6d 0a 0d 1b 5b 30 6d 1b 5b 31
;37m.[0m...[0m<[ 3b 33 37 6d 1b 5b 30 6d 0a 0d 1b 5b 30 6d 3c 5b
.[0;1;36m10000.[ 1b 5b 30 3b 31 3b 33 36 6d 31 30 30 30 30 1b 5b
0;0;37mX] [.[0;1 30 3b 30 3b 33 37 6d 58 5d 20 5b 1b 5b 30 3b 31
;36m30000.[0;0;3 3b 33 36 6d 33 30 30 30 30 1b 5b 30 3b 30 3b 33
7mL .[0;1;36m300 37 6d 4c 20 1b 5b 30 3b 31 3b 33 36 6d 33 30 30
00.[0;0;37mM .[0 30 30 1b 5b 30 3b 30 3b 33 37 6d 4d 20 1b 5b 30
;1;36m30000.[0;0 3b 31 3b 33 36 6d 33 30 30 30 30 1b 5b 30 3b 30
;37mV] [9:00 AM] 3b 33 37 6d 56 5d 20 5b 39 3a 30 30 20 41 4d 5d
> .[0m 3e 20 1b 5b 30 6d
Sent packet: 26 (9 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿú..R.6ÿð ff fa 1f 00 52 00 36 ff f0
Sent packet: 27 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿýV ff fd 56
Incoming packet: 19 (5 bytes) at Wednesday, June 29, 2011, 4:37:50 PM
ÿúVÿð ff fa 56 ff f0
Incoming packet: 15 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿþ. ff fe 18
Sent packet: 19 (3 bytes) at Wednesday, June 29, 2011, 4:37:49 PM
ÿü. ff fc 18
That's where it sent, and you can see the mud output text say the following:
TTYPE DO Sent -> Sent DO TTYPE to the client
TTYPE Request Recv -> We received some answer from the client
TTYPE WONT Recv -> We received WONT from the client
The 2 Recv messages were to make sure I wasn't mangling the message somehow and messing myself up, and falling to a default error condition.
No, there was no IAC WILL/WONT TTYPE in the sent packets listing, and there certainly wasn't any time for MUSHclient to respond in time for your messages to appear. Consider that MUSHclient got that whole packet at once. If your output is to be trusted, how did MUSHclient send a response before it even got the request?
I think your negotiation code might be bugged. Are you checking the state of the negotiation immediately after sending, or waiting a while, or...?
As I said, I'm using parts of KaVir's snippet code. When it starts negotiating, it tries TTYPE first. It will not negotiate the rest of the options (MSDP, NAWS, etc) until it gets this response. I too saw where it did not show in the debug output, but I can remove the negotiation of everything else and go again if you want.
Hmm. As it turns out, I can more or less reproduce this on the client-test mud I'm running. I can disable it fine, but sending IAC DO TTYPE results in not a single response from MUSHclient.
The weird thing is, Mushclient still responds to TTYPE subnegotiations if TTYPE is off.
EDIT: Just tested by setting up a raw server connection in Ruby and sending IAC SB TTYPE SEND IAC SE, and MUSHclient does indeed reply. So that's a bug too, albeit not a particularly onerous one.
Twisol, I think that was for legacy MUD servers that asked for a termtype without negotiation for it properly beforehand.
After carefully looking at the code, I finally worked out. There was a bug in the WONT handling, where it did not properly reset the flags, which should have allowed it to send a WILL afterwards. Fixed in version 4.76.
Nick Gammon said: Twisol, I think that was for legacy MUD servers that asked for a termtype without negotiation for it properly beforehand.
Yeah, that's what I figured. Not completely correct by the spec, but there's no real harm to it. A strict client would simply ignore it, leaving the MUD no better off.
