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

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Characters stripped during subnegotiation
Characters stripped during subnegotiation

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

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

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  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Mon 22 Aug 2011 11:29 PM (UTC)

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

12,767 views.

It is now over 60 days since the last post. This thread is closed.     [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.

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

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

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

[Best viewed with any browser - 2K]    [Hosted at HostDash]