How to Packet Sniff over UDP (TZSP Protocol)... !?

RouterOS General
1

Hi Guys,

I have been searching far and wide now for a proper implementation of packet sniffing tools and related.

I am a software developer and understand the TZSP protocol and that it is transported over UDP on port 37008.

I have done extensive research and know exactly how the packet and packet header is constructed.

But for some odd reason the information (RAW Packet Data) being sent over port 37008 (UDP) - does not conform to the proper implementation of the TZSP protocol!?

There seems to be a lot of “white spacing” between the TZSP Header and the actual “first” data being sent over.

I have read countless articles over the past two weeks of you should run WireShark, run this or that tool, etc…

I have even found the source of how to construct the packet with WireShark and the Syntax and related with the packet-tzsp.c information.

However I am seriously struggling to understand How RouterOS v6.2 sends sniffed packets down the wire; a sample of the “raw” data sent on UDP port 37008 would be:

01-00-00-01-01-00-00-00-00-00-00-00-00-00-00-00-00-08-00-45-00-00-28-…-00-00

I also need some assistance maybe from the guru’s at MikroTik on how to properly “dissect” this data being sent over the wire (as there seems to be blank data marked in red, etc… being sent; even though the “protocol and everything” seems to be “open source” this part seems to be “classified” as an industry secret?

I have been able to capture some information using WireShark, when disabling WCCP, etc…

However I would need more help on this as I am coding a utility that will properly be logging network traffic, and the only way I found that the most information can be logged is using packet sniffers.

Your help would greatly be appreciated - even if I can get some guys in on a the project to properly do this!

2

it seems to be padding after the header. That also could happen due to packet fragmentation, if that occurs when MTU of packet is reached.

3

As you see from TZSP header, encapsulation type is ethernet (0x00 0x01), so what follows TZSP header is ethernet packet that starts with ethernet header. These 0s are ethernet source and destination addresses. This can happen (ethernet source and destination set to all 0s) when sniffing on all interfaces or on interface that is not “ethernet like” and does not provide mac address info.

4

Hi Janisk,

Should I strip out padding, and how many “padded” characters are actually there, because sometimes this vary - the response is not always padded with the “[same] amount of padding”.

01-00-00-01-01-00-00-00-00-00-00-00-00-00-00-00-00-08-00-45-00-01-69-…

versus

01-00-00-01-01-00-0C-42-…

etc…

The issue here comes into play that what happens if the actual byte of the packet starts with [00] - then how would I be sure that this is not padding or part of the packet?

:confused:

Yes fragmentation can happen, but based on the “RAW” data how would one be able to know which packet is part of which fragmented section - as packet “fragments” seem to be coming in on UDP port 37008 in “random” order?

Is there anyone out there who maybe able to supply a “MikroTik Script” that could be used for an event system, example:

$event on_packet($packet) {

//Remove TZSP Header (this is not just the 4 byte +1 termination Header, as sometimes there maybe more to the Header than just that)

//Decapsulate the Packet (? I am not sure if this is required, and if it is required how to “decode” the encapsulated packet)

// Send RAW Packet to listening server

}

The best would be if we can see exactly how MikroTik structures the TZSP packets being sent over UDP 37008; because this will allow “us” to “dissect” the content on the receiver end…

5

to be honest - I never paid any attention to raw data stream coming out of ‘/tool sniffer’ when streaming to Wireshark from a router.

You could attempt so see what is the resulting Wireshark capture when showing capture and when sowing an encapsulated stream coming form router.

According to protocol documentation there should be no padding and encapsulated packet should start immediately after the tag fields, however there is exception allowed to have TAG_PADDING(0x00), that should be ignored.

6

Yes I fully agree with you but also according to documentation TAG_END (0x01) does not have anything after; more details:

TAG_PADDING = 0 (0x00)

This special tagged field has neither tag length nor any tag data. The receiver should ignore it. It is sometimes used to pack the frame to a word boundary.

TAG_END = 1 (0x01)

This special tagged field has neither tag length nor any tag data. This means that there are no more tags. Following this tag, until the end of the UDP packet, is the encapsulated frame. This is the only tag that is required and must be included before the encapsulated data. No variable tags can follow this one.

Which is why this is confusing, because:

01-00-00-01- ==> 01 <== this is TAG_END (0x01) -00-00-00-00-00-00-00-00-00-00-00-00-08-00-45-00-01-69

Have a look at:

http://en.wikipedia.org/wiki/User_Datagram_Protocol

Now according to mplsguy it could be that the source and destination are blank (0.0.0.0)

This would account for the first 8 bytes (that are blanked out)

==> 00-00-00-00 <== Source

==> 00-00-00-00 <== Destination

==> 00-00 <== Zero’s - as per UDP Header

==> 00-00 <== Protocol (why is this blank) ???

-08-00-45-00-01-69

Unless I am not understanding something here - but that it may in fact be the IP Header and not UDP - but if this is sent over UDP first comes the header and the content I assume would be the “Packet” that contains it’s own set of headers to classify the type, etc…

Unless they are padding the TZSP Header with 2 bytes per tag, example when they pad the TAG_END they also add one extra PAD 0 byte?

I will play around with it later tonight and see what I can find …

7

Just forget about padding and fragmentation, the capture you see has nothing to do with this (even more - according to TZSP spec any tagged fields, including padding, can NOT follow TAG_END). Everything is really simple, please study relevant specs carefully - TZSP, Ethernet, IP. You can use Wireshark to see the dissected packets (including TZSP header).

So here is the breakdown of your capture: 01-00-00-01-01-00-00-00-00-00-00-00-00-00-00-00-00-08-00-45-00-00-28-…-00-00

TZSP header: 01-00-00-01-01

  • version: 0x01
  • type: 0x00
  • ecapsulated protocol: 0x0001 - Ethernet - this means that what follows TZSP header is ethernet packet!
  • TAG_END: 0x1

So the rest that follows is ethernet packet: 00-00-00-00-00-00-00-00-00-00-00-00-08-00-45-00-00-28-…-00-00

It consists of ethernet header:
6 bytes destination MAC: 00-00-00-00-00-00
6 bytes source MAC: 00-00-00-00-00-00
2 bytes EtherType: 0x0800, meaning that it is IP packet inside Ethernet packet

The rest that follows is IP packet: 45-00-00-28-…-00-00
First byte (0x45) is pretty good indicator it is valid IP packet because 4 is IP version and 5 is standard IP header length in multiples of 4 bytes (20 bytes total).

8

as mplsguy states

versus

01-00-00-01-01> → 00-0C-42> -…

etc…

in red is start of mac address used in MikroTik products, in blue is end of TZSP header. Wonder why I did not notice it before.