Network Capture

Save network traffic into a capture file for further analysis. More...

Classes
class	NDDS::NetworkCaptureParams_t
	Input parameters for starting network capture. More...
class	NDDS::NetworkCapture
	Network Capture APIs. More...

Enumerations
enum	NDDS::NetworkCaptureContentKind : UINT32 {   NDDS::NetworkCaptureContentKind::USER_SERIALIZED_DATA,   NDDS::NetworkCaptureContentKind::ENCRYPTED_DATA,   NDDS::NetworkCaptureContentKind::MASK_DEFAULT,   NDDS::NetworkCaptureContentKind::MASK_NONE,   NDDS::NetworkCaptureContentKind::MASK_ALL }
	Bitmap used to specify a content type, i.e., a part of the RTPS frame. More...
enum	NDDS::NetworkCaptureTrafficKind : UINT32 {   NDDS::NetworkCaptureTrafficKind::TRAFFIC_OUT,   NDDS::NetworkCaptureTrafficKind::TRAFFIC_IN,   NDDS::NetworkCaptureTrafficKind::MASK_DEFAULT,   NDDS::NetworkCaptureTrafficKind::MASK_NONE,   NDDS::NetworkCaptureTrafficKind::MASK_ALL }
	Bitmap used to specify whether we want to capture inbound or outbound traffic. More...

Detailed Description

Save network traffic into a capture file for further analysis.

RTI Connext allows you to capture the network traffic that one or more DomainParticipants send or receive. This feature can be used to analyze and debug communication problems between your DDS applications. When network capture is enabled, each DomainParticipant will generate a pcap-based file that can then be opened by a packet analyzer like Wireshark, provided the right dissectors are installed.

To some extent, network capture can be used as an alternative to existing pcap-based network capture software (such as Wireshark). This will be the case when you are only interested in analyzing the traffic a DomainParticipant sends/receives. In this scenario, network capture will actually have some advantages over using more general pcap-based network capture applications: RTI's network capture includes additional information such as security-related data; it also removes information that is not needed, such as user data, when you want to reduce the capture size. That said, RTI's network capture is not a replacement for other pcap-based network capture applications: it only captures the traffic exchanged by the DomainParticipants, but it does not capture any other traffic exchanged through the system network interfaces.

To capture network traffic NDDS::NetworkCapture::enable must be invoked before creating any DomainParticipant. Similarly, NDDS::NetworkCapture::disable must be called after deleting all participants. In between these calls, you may start, stop, pause or resume capturing traffic for one or all participants.

Capturing Shared Memory Traffic

Every RTPS frame in network capture has a source and a destination associated with it. In the case of shared memory traffic, a process identifier and a port determine the source and destination endpoints.

Access to the process identifier (PID) of the source for inbound traffic requires changes in the shared memory segments. These changes would break shared memory compatibility with previous versions of RTI Connext. For this reason, by default, network capture will not populate the value of the source PID for inbound shared memory traffic.

If interoperability with previous versions of RTI Connext is not necessary, you can generate capture files containing the source PID for inbound traffic. To do so, configure the value of the 'dds.transport.minimum_compatibility_version' property to 6.1.0. (See DDS::PropertyQosPolicy).

<domain_participant_qos> 
     <property> 
         <value> 
             <element> 
                 <name>dds.transport.minimum_compatibility_version</name> 
                 <value>6.1.0</value> 
                 <propagate>false</propagate> 
             </element> 
         </value> 
     </property> 
 </domain_participant_qos> 

This property is never propagated, so it must be consistently configured throughout the whole system.

Note: Changing the value of this property affects the type of shared memory segments that RTI Connext uses. For that reason, you may see the following warning, resulting from leftover shared memory segments:

[0xC733A001,0xB248F671,0xAEC4A0C1:0x000001C1{D=200}|CREATE DP|ENABLE] NDDS_Transport_Shmem_is_segment_compatible:incompatible shared memory protocol detected. Current version 4.0 not compatible with 2.0. 

The leftover shared memory segments can be removed using the ipcrm command. See https://community.rti.com/kb/what-are-possible-solutions-common-shared-memory-issues for more information.

Enumeration Type Documentation

NetworkCaptureContentKind

enum NDDS::NetworkCaptureContentKind : UINT32

strong

Bitmap used to specify a content type, i.e., a part of the RTPS frame.

Several values can be combined. Read NDDS::NetworkCaptureContentKind for typical combinations.

Enumerator
USER_SERIALIZED_DATA	The serialized data coming from a user.
ENCRYPTED_DATA	The encrypted user data.
MASK_DEFAULT	Default mask for NDDS::NetworkCaptureContentKind: do not remove any content. It is equivalent to MASK_NONE. [default] Do not remove any content.
MASK_NONE	The RTPS frames in the capture file will be saved as they are.
MASK_ALL	The RTPS frames in the capture file will not include user data (either plain or encrypted). Its value is the result of setting the bits for removing user data and removing encrypted data: (USER_SERIALIZED_DATA) | ENCRYPTED_DATA)

NetworkCaptureTrafficKind

enum NDDS::NetworkCaptureTrafficKind : UINT32

strong

Bitmap used to specify whether we want to capture inbound or outbound traffic.

Several values can be combined. Read NDDS::NetworkCaptureTrafficKind for typical combinations.

Enumerator
TRAFFIC_OUT	Do not capture outbound traffic.
TRAFFIC_IN	Do not capture inbound traffic.
MASK_DEFAULT	Default mask for NDDS::NetworkCaptureTrafficKind. It is equivalent to MASK_ALL. [default] Capture all traffic: inbound and outbound.
MASK_NONE	Do not capture any traffic.
MASK_ALL	Capture all traffic (both inbound and outbound). The value is equal to setting both the input and output bits of the mask: (TRAFFIC_OUT | TRAFFIC_IN).