You must be logged in to post Login

Lost Your Password?

Search Forums:


Wildcard Usage:
*    matches any number of characters
%    matches exactly one character

Listener crashes (Needs boundschecking)


1:30 pm
March 17, 2011




posts 3

Hi Paul,


First of all great library you made, I am using it for a while already!

I do have some concerns relating to OSC address formatting.


I am using the UDP server transport for listening to OSC messages.

The port I use is 10000 and it seems that this port is used by script kiddies alike to scan the internet and send garbage to that (udp) port. As a result this crashes the OSC udp server.

I am a C# beginner (and dutch) so forgive me if the following sentence is wrongly stated but in my own words I would describe the cause as following:

Cause of server crashing:

As soon as you send a non proper formatted OSC messages to the OSC UDP Client listener, the function routine: "ValueFromByteArray" in the OscPacket class wil give a system.IndexOutofRangeException because of the 'for itteration' not doing any boundschecking on the data[index] array.


You can replay this problem using the tool: "netcat.exe" and send udp data to your server. For example:

"nc 10000 -u -vv" After this you can send ASCII chars to the udp port after after hitting <enter>



I solved some parts of the code by doing boundschecking on the "data" array by implementing:

if ((data.GetUpperBound(0) <=1) &&  (start <= data.GetUpperBound(0))

I would like to know if this is the way to go or is there a better way ?






11:24 am
March 19, 2011



posts 49

Hi Marcel,

First, sorry it's taken me awhile to respond. When I saw your post, I remember you'd asked this question before. I've been working on my PhD dissertation and have just now come up for air.

To your question. The fix to that specific loop is as follows:

for (int index = start; index < data.Length && data[index] != 0; index++)

You were correct, I wasn't bounds checking access to the byte array. However, to address the complete question of malformed OSC packets, fixing this array isn't enough. Assume for a moment, that the first few bytes that come in (which in OSC are supposed to be the OSC "address" — for example "/somestring") aren't a bona-fide OSC address. When building the OSC message, my library will "Assert" that it should find the OSC address first, and promptly throw an exception. This exception isn't handled by the OscServer.DataRecieved() method and bubbles up, likely to the default exception handler halting your application.

So, there's more to this. I'm looking into it now and will respond shortly.




8:39 pm
March 19, 2011



posts 49

Ok, I think I've added what you need to address this issue. Specifically, I've included the notion of OscServer.ConsumeParseExceptions (enabled by default) which suppresses parsing exceptions caused by malformed OSC packets.

I've released a new version of the library, version 1.6, which you can find at…..page_id=69.

Please let me know if this does the trick.


8:06 am
March 20, 2011




posts 3



Wow, that is incredible fast! I will let you know as soon as possible.


Thank you,



About the Bespoke Software forum

No Comment

Comments are closed.