[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Characters stripped during subnegotiation
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Characters stripped during subnegotiation

It is now over 60 days since the last post. This thread is closed.   [New subject]  Start a new subject   [Refresh] Refresh page


Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Mon 22 Aug 2011 08:50 PM (UTC)  quote  ]

Amended on Mon 22 Aug 2011 11:31 PM (UTC) by KaVir

Message
I'm running into some problems when receiving certain characters in MSDP subnegotiation sequences, and was wondering if anyone might know the cause, and perhaps a solution. For testing purposes, I used the following simple function:


local MSDP = 69
function OnPluginTelnetSubnegotiation (type, data)
  if type == MSDP then
    testdata = ""
    for i=0,string.len(data),1 do
      if string.byte(data,i) ~= nil then
        testdata = testdata..string.byte(data,i).." "
      end -- if
    end -- loop
    Note('['..testdata..']')
  end -- if
end -- OnPluginTelnetSubnegotiation

The mud sends the following sequence:

IAC SB MSDP MSDP_VAR "TEST" MSDP_VAL "abcde*edcba" IAC SE

EDIT: Corrected the order of MSDP_VAR and MSDP_VAL.

Note that the quotes aren't sent, they just represent the start and end of a string. MSDP_VAR is 1, MSDP_VAL is 2, and the * is replaced with values 1-12. The results are between the square brackets, as follows:

1: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 1 101 100 99 98 97] IAC SE

2: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 2 101 100 99 98 97] IAC SE

3: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101] IAC SE

4: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 101 100 99 98 97] IAC SE

5: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101] IAC SE

6: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 6 101 100 99 98 97] IAC SE

7: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 7 101 100 99 98 97] IAC SE

8: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 8 101 100 99 98 97] IAC SE

9: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 100 99 98 97] IAC SE

10: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 10 101 100 99 98 97] IAC SE

11: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 11 101 100 99 98 97] IAC SE

12: IAC SB MSDP [1 84 69 83 84 2 97 98 99 100 101 12 101 100 99 98 97] IAC SE

As you can see, most of them are correct, but four of the characters have unexpected results:

3 (ETX/end of text) chops off the sequence and corrupts the next one.
4 (EOT/end of transmission) vanishes from the sequence.
5 (ENQ/enquiry) chops off the sequence and corrupts the next one.
9 (TAB/horizontal tab) vanishes from the sequence and takes the next character with it.

Now I can understand these characters being stripped from the in-band stream, but this is an out-of-band subnegotiation sequence.

Is this a bug, or an unavoidable side-effect of something else?

I tested it with versions 4.51 and 4.73, both had the same results.
[Go to top] top

Posted by Nick Gammon   Australia  (19,670 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Mon 22 Aug 2011 11:29 PM (UTC)  quote  ]

Amended on Mon 22 Aug 2011 11:30 PM (UTC) by Nick Gammon

Message
I can't reproduce that, sorry. I used your test in a plugin, and fed in data using Game -> Test Trigger, as follows:


\FF\FA\45\02TEST\01abcde\03edcba\FF\F0
\FF\FA\45\02TEST\01abcde\04edcba\FF\F0
\FF\FA\45\02TEST\01abcde\05edcba\FF\F0
\FF\FA\45\02TEST\01abcde\09edcba\FF\F0


I am guessing you got MSDP_VAR and MSDP_VAL backwards in your explanation, because the first thing I see is 1, not 2.

However here are my results for 3, 4, 5, 9:


[2 84 69 83 84 1 97 98 99 100 101 3 101 100 99 98 97 ]
[2 84 69 83 84 1 97 98 99 100 101 4 101 100 99 98 97 ]
[2 84 69 83 84 1 97 98 99 100 101 5 101 100 99 98 97 ]
[2 84 69 83 84 1 97 98 99 100 101 9 101 100 99 98 97 ]



Nothing dropped or corrupted. Possibly the server is doing something to the outgoing stream?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Reply #2 on Mon 22 Aug 2011 11:47 PM (UTC)  quote  ]
Message
Sorry, yes, I mixed up MSDP_VAR and MSDP_VAL in the explanation - I've corrected it and put an "EDIT" note.

If it works for you then it must be at the server end. This was something I was adding to someone else's mud (nested MSDP tables and arrays), but I should probably have added it to my own mud first, where I know exactly what it's doing. Many thanks for the help.
[Go to top] top

Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Reply #3 on Mon 29 Aug 2011 08:57 AM (UTC)  quote  ]
Message
Just to confirm (in case anyone else stumbles across this issue when following the latest MSDP specification, and finds this thread with a search), this problem was indeed caused at the server end. It works fine in Merc and SMAUG, and probably most other codebases.
[Go to top] 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.


2,026 views.

It is now over 60 days since the last post. This thread is closed.   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]