locked
Custom parser triggered by data header in UDP Payload? RRS feed

  • Question

  • Hi,

    I am writing a simple parser (.npl) for debugging a UDP datastream from a software developed inhouse.

    I have got it working so that it can parse all the data.

    I register my parser in my_sparser.npl with:

    [ RegisterAfter (UDPPayload.WinsRpl, MyPacketType, 5003) ]

    This makes Microsoft network monitor able to read my packets correctly. BUT since the data could be sent via a user defined UDP port (destination port) I would like to be able to detect the incoming packets but payload header instead of destination port. The packets all share a simple 4 byte header (i.e. 0x53455044).

    How do I register my parser to pick up these packages by the header in the UDPpayload and NOT by destination port?

    Friday, September 6, 2013 8:44 AM

Answers

  • Actually I just checked my parsers and UDP doesn't have WinsRpl referenced in it.  The registration of WinsRpl also done dynamically and is based on SSRP which is a simple switch statement.  For a simple switch it looks for just a port number.

    Instead trying registering in relation to WSP, since that is in a place where we don't have a simple switch statement.  BTW, make sure you are using the latest parsers from www.connect.com/site216. When I tried this I was able to get it to work.

    [RegisterAfter (UDPPayload.WSP, MyPacketType, UINT32(FrameData, FrameOffset) == 0x53455044)]
    Protocol paultest
    {
    }

    Just to be clear, this is the hex data I used at the UDP header and payload.  Also the fixed port addresses have priority and will hit before this one.  Not sure if that might be an issue.

    02 42 01 23 00 6D E0 1B 53 45 50 44 00 08 00 02 00 00 00 01 00 0E 00 01 00 01 18 B9 AC 33 00 15 5D 40 3C 01 00 03 00 0C 12 00 15 5D 00 00 00 00 00 00 00 00 00 27 00 17 00 08 32 30 30 38 52 32 44 43 07 62 72 6F 74 6F 73 6F 03 63 6F 6D 00 00 10 00 0E 00 00 01 37 00 08 4D 53 46 54 20 35 2E 30 00 06 00 08 00 18 00 17 00 11 00 27

    • Marked as answer by Björn Blissing Thursday, September 26, 2013 12:13 PM
    Tuesday, September 24, 2013 10:21 PM

All replies

  • You should be able to do something like:

    [RegisterAfter (UPPayload.WinsRpl, MyPacketType, UINT32(FrameData, FrameOffset) == 0x53455044)]

    There are some examples if you search the NPL code we ship which is in the ProgramData folder. 

    Hope that helps,

    Paul

    • Marked as answer by Paul E Long Wednesday, September 11, 2013 1:56 PM
    • Unmarked as answer by Björn Blissing Thursday, September 12, 2013 11:01 AM
    Wednesday, September 11, 2013 1:47 PM
  • No, this does not really work. I tried to add two different packet types.

    [RegisterAfter (UDPPayload.WinsRpl, MyPacketType1, UINT32(FrameData, FrameOffset) == 0x53455044)]
    ...
    [RegisterAfter (UDPPayload.WinsRpl, MyPacketType2, UINT32(FrameData, FrameOffset) == 0x53455045)]
    ...

    But when parsing Network Monitor seems to disregard the equality test. So all UDP Payloads are parsed as if they were of MyPacketType1 regardless of their header.

    If I change the order of the parser includes in the my_sparser.npl then all UPD payloads are parsed as if they were of MyPacketType2 regardless of header.

    Regards

    Björn


    Thursday, September 12, 2013 11:01 AM
  • Actually I just checked my parsers and UDP doesn't have WinsRpl referenced in it.  The registration of WinsRpl also done dynamically and is based on SSRP which is a simple switch statement.  For a simple switch it looks for just a port number.

    Instead trying registering in relation to WSP, since that is in a place where we don't have a simple switch statement.  BTW, make sure you are using the latest parsers from www.connect.com/site216. When I tried this I was able to get it to work.

    [RegisterAfter (UDPPayload.WSP, MyPacketType, UINT32(FrameData, FrameOffset) == 0x53455044)]
    Protocol paultest
    {
    }

    Just to be clear, this is the hex data I used at the UDP header and payload.  Also the fixed port addresses have priority and will hit before this one.  Not sure if that might be an issue.

    02 42 01 23 00 6D E0 1B 53 45 50 44 00 08 00 02 00 00 00 01 00 0E 00 01 00 01 18 B9 AC 33 00 15 5D 40 3C 01 00 03 00 0C 12 00 15 5D 00 00 00 00 00 00 00 00 00 27 00 17 00 08 32 30 30 38 52 32 44 43 07 62 72 6F 74 6F 73 6F 03 63 6F 6D 00 00 10 00 0E 00 00 01 37 00 08 4D 53 46 54 20 35 2E 30 00 06 00 08 00 18 00 17 00 11 00 27

    • Marked as answer by Björn Blissing Thursday, September 26, 2013 12:13 PM
    Tuesday, September 24, 2013 10:21 PM
  • Ok, well the missing WinRpl from the UDPPayload was the reason for the odd registration. I will have to blame copy paste since I didn't really get how the registration of own parsers worked. And the documentation did not give any crystal clear examples.

    Btw, the link you supplied in your answer is probably wrong.

    Thursday, September 26, 2013 12:16 PM
  • You are right, the link for connect is http://connect.microsoft.com/site216.  You'll have to sign-in and join our connection to see the downloads for parsers.

    Paul

    Monday, September 30, 2013 2:11 PM