3. Capturing DDS traffic¶

eProsima Non-Intrusive DDS Recorder processes a capture file; it does not produce one. The quality of the recording therefore depends entirely on how the capture was taken, and a capture that looks fine in a protocol analyzer may still be unusable here. This section describes what eProsima Non-Intrusive DDS Recorder expects from a capture file and how to obtain one.

3.1. What the capture needs¶

Requirement	Why
Complete packets	eProsima Non-Intrusive DDS Recorder discards every packet whose captured length differs from its length on the wire, so a capture taken with a reduced snapshot length yields an empty or incomplete database.
The discovery phase	The data type schema and the topic-to-endpoint mapping are learned from the discovery traffic. A capture started after the applications have discovered each other contains user samples that eProsima Non-Intrusive DDS Recorder cannot interpret.
A supported link layer	Ethernet, loopback, Linux cooked capture (the `any` interface) and raw IP are understood. Any other link layer is reported when the file is opened. See Supported link layers.
IPv4 and UDP	RTPS over UDP/IPv4 is dissected. Traffic over IPv6 or TCP is not recognized.
Unencrypted RTPS	The dissector reads the RTPS submessages directly, so traffic protected with DDS Security cannot be decoded.

See Limitations and troubleshooting for the complete list.

3.2. Where to capture¶

A network interface in the default configuration only receives the traffic addressed to its own node, which for a DDS system means the multicast discovery traffic plus the samples that this particular node has subscribed to. That is enough to record a single application, but not a whole system.

To record every participant of a DDS network, capture on a mirror port of the switch, also known as the switch debug port, configured to duplicate the traffic of the ports where the DDS nodes are connected.

Note

Discovery is largely multicast, while user samples are frequently sent unicast to each matched reader. A capture point that sees the multicast traffic but not the unicast traffic produces a database with populated Topics and Endpoints tables and no samples.

If all the applications run on the same host, capture on the loopback interface instead: lo on Linux, lo0 on macOS and the BSDs, and the loopback adapter provided by Npcap on Windows.

When the participants are spread over several interfaces of the same host, or you are not sure which interface carries the traffic, capture on the Linux any pseudo-interface, which records every interface at once:

sudo tcpdump -i any -s 0 -w capture.pcap udp

eProsima Non-Intrusive DDS Recorder understands the Linux cooked capture link layer that any produces, in both its v1 and v2 forms, as well as the loopback link layers of every supported platform. Supported link layers lists them all.

Note

A capture taken on any contains the same packet more than once when it crosses two captured interfaces, and loopback traffic is normally seen twice, once on transmission and once on reception. Both show up as repeated samples in the database; Querying the recorded database shows how to detect them.

3.3. Capturing with Wireshark¶

In the Capture Options dialog:

Select the interface connected to the switch mirror port.
Leave the snapshot length at its default (default means unlimited). Do not set a limited value: a truncated capture is rejected packet by packet.
Optionally set a capture filter to keep the file small, for example udp.
Start the capture, then start the DDS applications, so that the discovery phase is included.
Stop the capture and save the file.

3.4. Capture file formats¶

Both the classic pcap format and the pcapng format that Wireshark writes by default are accepted, as far as the libpcap runtime in use can read them.

Important

On Windows that runtime is not part of the operating system, and the choice matters. Npcap reads both formats. The older WinPcap, whose last release embeds libpcap 1.0, predates pcapng and cannot open such a file at all: eProsima Non-Intrusive DDS Recorder reports Number of processed RTPS packets: 0 and writes an empty database. See Windows.

A pcapng file can be converted to the classic format, which every runtime reads:

editcap -F pcap capture.pcapng capture.pcap

3.5. Capturing from the CLI¶

The same capture can be taken without a graphical interface. With tcpdump, the -s 0 flag requests full packets and -w writes the classic pcap format:

sudo tcpdump -i eth0 -s 0 -w capture.pcap udp

The equivalent with tshark is:

sudo tshark -i eth0 -s 0 -w capture.pcap udp

To restrict the capture to a single DDS domain, filter by the port range that the domain uses. The RTPS ports derive from the Domain Id, so the simplest reliable approach is to capture all UDP traffic and let eProsima Non-Intrusive DDS Recorder ignore whatever is not RTPS.

3.6. Checking a capture file¶

Before recording a long capture, confirm that it contains what you expect. Wireshark decodes RTPS out of the box, so the display filter rtps shows the RTPS packets in the file, and rtps.sm.id == 0x15 narrows it down to the DATA submessages that carry discovery announcements and user samples.

The equivalent check from the command line is:

tshark -r capture.pcap -Y rtps -T fields -e frame.number -e rtps.sm.id | head

Finally, run eProsima Non-Intrusive DDS Recorder itself: the Number of processed RTPS packets line it prints is the number of packets it was able to recognize, and it is the fastest way to tell a capture problem from a recording problem.