Gammon Forum : MUSHclient : Bug reports : Characters stripped during subnegotiation

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

Characters stripped during subnegotiation

Characters stripped during subnegotiation

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

Posted by KaVir Germany (117 posts) 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.

top

Posted by Nick Gammon Australia (23,042 posts) 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

top

Posted by

KaVir Germany (117 posts)

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.

top

Posted by

KaVir Germany (117 posts)

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.

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.

13,517 views.

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

Go to topic: Search the forum

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.