Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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 ➜ Terminal Type Re-Enabling On Copyover
Terminal Type Re-Enabling On Copyover

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Mleo2003   (32 posts)  Bio
Date Wed 29 Jun 2011 04:09 AM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 29 Jun 2011 08:42 AM (UTC)
Message
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?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #2 on Wed 29 Jun 2011 02:58 PM (UTC)
Message
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.
Top
Posted by KaVir   Germany  (117 posts)  Bio
Date Reply #3 on Wed 29 Jun 2011 06:42 PM (UTC)
Message
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.
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #4 on Wed 29 Jun 2011 07:12 PM (UTC)
Message
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.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #5 on Wed 29 Jun 2011 08:45 PM (UTC)

Amended on Wed 29 Jun 2011 08:47 PM (UTC) by Twisol

Message
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.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #6 on Wed 29 Jun 2011 10:01 PM (UTC)
Message
Template:post=3061 Please see the forum thread: http://gammon.com.au/forum/?id=3061.


MUSHclient does not repeatedly acknowledge the same mode (it remembers, per option, what it last sent (do/dont/will/wont)).

However as you have noted if you send DONT that is a new mode, and it is acknowledged. Then you can send DO again and get a response.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #7 on Wed 29 Jun 2011 10:05 PM (UTC)
Message
That I can Nick. Only thing is, that response to that DO after being told DONT and getting back WONT, is another WONT.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #8 on Wed 29 Jun 2011 10:14 PM (UTC)

Amended on Wed 29 Jun 2011 10:17 PM (UTC) by Twisol

Message
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 :)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #9 on Wed 29 Jun 2011 10:43 PM (UTC)
Message
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
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #10 on Wed 29 Jun 2011 11:01 PM (UTC)
Message 
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

Requested to disable, and acknowledged...

Incoming packet: 18 (534 bytes) at Wednesday, June 29, 2011, 4:37:49 PM

~snip~
PLAYING!..ÿý.TTY   50 4c 41 59 49 4e 47 21 0a 0d ff fd 18 54 54 59
~snip~

Requested to enable... I don't see any response from MUSHclient after this point.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #11 on Wed 29 Jun 2011 11:15 PM (UTC)
Message
While I am looking at the telnet stuff, this is wrong:


..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


A line should end with CR/NL (0x0D 0x0A) not NL/CR. The NL/CR is not a valid sequence.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #12 on Wed 29 Jun 2011 11:17 PM (UTC)
Message
Not in the packets, but like I said, I setup the Debug output from the mud to make sure and see what it see's. 

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


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.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #13 on Wed 29 Jun 2011 11:21 PM (UTC)
Message
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...?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Mleo2003   (32 posts)  Bio
Date Reply #14 on Wed 29 Jun 2011 11:25 PM (UTC)
Message
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.
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.

61,852 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home