2. Wireshark Features for Packet Analysis

2.2. User Data Dissection

Wireshark allows you to dissect the fields of user data samples. There are just two requirements:

  • The captured Data Reader (DATA(r)) or Data Writer (DATA(w)) discovery packets must contain the Type Object.

  • The data representation kind is set to CDR (CDR2 not supported).

This feature can significantly increase dissection time, so it is not enabled by default. To enable it, select Edit >> Preferences. In the Preferences window, select RTPS from the Protocols on the left and enable the checkbox for Enable User data Dissection (based on Type Object).


This feature is not available in the latest Stable Release (3.2.4) as of 6/26/2020. Until there is a newer Stable Release, this feature will only be available in the nightly builds.

Enable Dissection

This feature allows you to dissect the Type Object and user data, even if it is compressed (only ZLIB compression is supported by the dissector).

2.2.1. Viewing Type Object Dissection

Once the feature is enabled, if a DATA(r) or DATA(w) is captured, Wireshark will dissect the Type Object of the selected packet. To see the Type Object dissection, select a packet. In the dissection tree, look under Real-Time Publish Subscribe Wire Protocol, SubMessageId DATA, serializedData, serializedData, PID_TYPE_OBJECT[_LB], Type Object.

The following image shows the dissection of a compressed Type Object of a type called Example test with a single int32 member called x.

Dissected Type Object

2.2.2. Viewing User Data Dissection

To see the user data dissection, select a User Data packet (DATA). In the dissection tree, look under Real-Time Publish Subscribe Wire Protocol, SubMessageId DATA, serializedData, [TYPE MEMBERS], where TYPE MEMBERS is the Data Type hierarchy.

The following image shows the dissection of a type with a top-level struct called test with a single int32 member called x.

User Data dissection

2.2.3. Limiting Elements in Sample Packets

The dissector can take a long time to process packets with large arrays or sequences. To speed up the process, you can limit the number of elements displayed when dissecting Type Object and user data samples.

RTPS Dissector includes the option to enable or disable element limitations and specify the maximum number of elements to display for arrays/sequences and structs. For example, the elements displayed for a type with the following structure can be limited to prevent Wireshark from slowing down.

     long member1
     double member2
     string member3
     string member1000
     double a
     boolean b
     string c

If you limit elements for the above structure to ten, Wireshark displays the number of elements noted in Table 2.1.

Table 2.1 Limit Elements for a Structure


Elements Displayed


2 of 2


The first 10 of 1000


3 of 3

If you limit the number of displayed elements shown in arrays or sequences, Wireshark likewise displays only up to the number of elements you specify. For example, if you have an array of 100 integers, and elements for arrays or sequences is limited to ten, only the first ten integers would display.

To limit the number of elements,

  1. In Wireshark, go to Edit > Preferences.

  2. On the left, select Protocols > RTPS.

  3. To Limit the number of elements dissected in structs, select the checkbox and then enter the desired maximum.

    Limit Struct Elements
  4. To Limit the number of elements dissected in arrays or sequences, select the checkbox and then enter the desired maximum.

    Limit Array/Sequence Elements

2.2.4. RTPS Checksum Check

Packets with the RTPS_HE (Header Extension) available include a checksum for detecting corrupted packets. Wireshark can check if the packet is corrupted by calculating the RTPS message checksum and comparing it with the expected checksum in the header extension. This feature supports CRC-32C and MD5 checksums only.

To enable this feature, go to Preferences > Protocols > RTPS and select the option Enable RTPS Checksum check. This option is disabled by default.

Enable RTPS Checksum Check

Once enabled, Wireshark reviews the checksums where available. If the expected and calculated checksums are different, an error displays in the Expert Information dialog, as shown below.

Expert Info Error

2.3. Packet Options

Right-clicking on a packet in the Columns view will give you several options. The ones in red (below) are commonly used for analysis of RTPS:

Packet Options
  • Mark/Unmark: Marks the packet in black or unmarks it. This is useful for filtering (frame.marked == 1) or exporting only marked packets.

  • Ignore/Unignore: Ignores a packet, so it is displayed as “Ignored”. This is useful when packets are not related to your analysis and you don’t want them to be present in your analysis (instead of filtering them out).

  • Set/Unset Time Reference: Makes the time of the selected packet be the time reference for all the packets captured after it. Several time references can be used.

  • Time Shift: Allows you to change the time of the packets.

    Shifting Time
  • Packet Comment: Useful for providing comments to another colleague. For example, you can add the comments to the packets and then filter using “pkt_comment” to only display the packets with comments. Another option is to add the comment as a column:

    Packet Comment
  • Edit Resolved Name: Useful for replacing IP addresses with actual names. If DNS information is available in the capture, Wireshark will use it. You can also overwrite those names or enter new names. You must first enable this feature in Preferences, Name Resolution.

Name Resolution
  • Protocol Preferences: This is another way set protocol preferences instead of choosing the RTPS protocol in the Preferences menu. Protocol Preferences show the preferences available to configure (for example, the Topic Information feature).

2.4. Layer Options

Wireshark shows all the protocols contained in a packet. This is called the Layer view. The Layer view can be used to display the content of each layer.

Layer View

The Internet Protocol Version 4 (IP) contains useful information:

IPv4 Layer
  • Identification: All the IP packets containing the same Identification represent the same payload. For example, if a UDP datagram is split into ten IP packets, those ten packets contain the same Identification.

  • Flags: “More fragments” will be 1 if more fragments are expected for this Identification. In the example above, the first nine IP packets will have “More fragments” set to 1, and the last IP packet will have “More fragments” set to 0.

  • Source and Destination IP addresses.

From the UDP Layer, you can get the ports used for communication. The fields of the RTPS layer will be explained in the next section. For every field shown in the Layer view, you can right-click to get these menu options:

Layer View Options

The more commonly used options in RTPS analysis are:

  • Apply as Column: Makes this field a column in the Packet columns view. This is useful when analyzing specific problems in RTPS. For example, showing the Sequence Number of the RTPS submessages is very helpful when analyzing reliability problems.

  • Apply as Filter: Uses the field to create a filter and applies it. Useful when the filter expressions are not known (for example, if you want to filter by this Writer but don’t know the expression to do it).

  • Prepare a Filter: Same as above but without applying the filter. It just shows the filter; you have to press “enter” to apply it.

  • Colorize with Filter: Colorizes the packets that pass the filter (i.e., the packets that contain the selected field). This is useful for differentiating the packets instead of filtering them out.

  • Copy: Copies the field in the specified format.

    Copy Options

The ICMP layer is also important in the analysis of problems. ICMP messages inform you when the destination is unreachable, when TTL is exceeded, fragment reassembly time is exceeded, and so on. More information is here: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol.

2.5. Topic Information Feature

There isn’t any information in the DATA submessage that directly indicates the associated Topic or Type. The information needed to find the Topic or Type for a given sample is given in the discovery phase.

  • The DATA submessage contains the DataWriter GUID (GUID Prefix + WriterEntityId).

  • The discovery information contains the mapping between the DataWriter GUID and the Topic.

Wireshark can correlate the discovery traffic and the DATA submessages for you. This feature is called Topic Information. To enable it, right-click on any RTPS packet and select Protocol Preferences >> Enable Topic Information feature:

Enabling Topic Information Feature

If the discovery data associated with a DataWriter is available in the Wireshark capture, Wireshark will show the Topic Information subtree inside the submessage:

Showing Topic Information

And the columns view will show the Topic Name:

Column Shows Topic Name

In addition, the topic and type filters will show all the packets related to the topic and filter (including HEARTBEAT, ACKNACK, DATA, etc):

Showing Related Packets
Example Filter Entry

When Wireshark shows the Topic Information for a given DATA submessage, it tries to dissect the Serialized Data (the CDR byte array) by calling a dissector registered for that Type Name. If the dissector happens to be registered, the data will be passed to that dissector. This means you can create your own User Data dissectors and have Wireshark call them. If the dissector is not registered (default behavior), it will show the CDR byte array. It is your responsibility to write a dissector for your specific type (IDL).