Characters stripped during subnegotiation

Posted by KaVir on Mon 22 Aug 2011 08:50 PM — 4 posts, 18,343 views.

KaVir Germany Mon 22 Aug 2011 08:50 PM #0

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.

Nick Gammon Australia Forum Administrator Mon 22 Aug 2011 11:29 PM #1

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?

KaVir Germany Mon 22 Aug 2011 11:47 PM #2

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.

KaVir Germany Mon 29 Aug 2011 08:57 AM #3

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.