-
Notifications
You must be signed in to change notification settings - Fork 50
Supported Trace Formats
Format | URI | Input | Output | Notes |
---|---|---|---|---|
Live pcap interface | pcapint:<interface> | Yes | Yes | |
pcap trace file | pcapfile:<filename> | Yes | Yes | |
pcag-ng trace file | pcapng:<filename> | Yes | Yes | Read support added in libtrace 4.0.2, write support added in libtrace 4.0.6 |
ERF trace file | erf:<filename> | Yes | Yes | |
DAG device | dag:<device location> | Yes | Yes | Requires DAG hardware capture card and libraries |
Native Linux interface | int:<interface> | Yes | Yes | Only available on Linux |
Native Linux interface (ring buffers) | ring:<interface> | Yes | Yes | Only available on Linux -- requires Libtrace 3.0.16 or later |
Data Plane Development Kit (DPDK) | dpdk:<PCI address> | Yes | Yes | Requires a DPDK compatible NIC + additional setup |
Data Plane Development Kit (DPDK) virtual device | dpdkvdev:<device type>,iface=<device name> | Yes | Yes | |
Native BSD interface | bpf:<interface> | Yes | No | Only available on BSD or Mac OS X |
TSH trace file | tsh:<filename> | Yes | No | |
FR+ trace file | fr+:<filename> | Yes | No | |
Legacy DAG ATM trace file | legacyatm:<filename> | Yes | No | |
Legacy DAG POS trace file | legacypos:<filename> | Yes | No | |
Legacy DAG Ethernet trace file | legacyeth:<filename> | Yes | No | |
Legacy DAG NZIX trace file | legacynzix:<filename> | Yes | No | |
ATM cell header trace file | atmhdr:<filename> | Yes | No | |
RT network protocol | rt:<host>:<port> | Yes | No | |
nDAG protocol | ndag:<interface>,<multicast group>,<port> | Yes | No | |
nDAG protocol via DPDK | dpdkndag:<PCI address> | Yes | No | Only available on Linux -- experimental (requires additional setup) |
nDAG protocol via TCP | ndagtcp:<interface>,<listen address>,<port> | Yes | No | Added in libtrace 4.0.23 |
TZSP | tzsplive:<host>:<port> | Yes | Yes | Added in libtrace 4.0.7 |
XDP | xdp:<interface> | Yes | Yes | Added in libtrace 4.0.14 |
ETSI LI live handover | etsilive:<ip address>:<port> |
Yes | No | Added in libtrace 4.0.4 |
ETSI LI trace file | etsifile:<filename> |
Yes | Yes | Added in libtrace 4.0.21 |
Libtrace input and output sources are specified using URIs which describe both the format and location of the trace, interface or device in question. To do so, simply append the location of the trace file, interface or device to the URI for the appropriate format as specified in the table above.
For example, pcapfile:sample.pcap.gz
describes the PCAP trace file called sample.pcap.gz. dag:/dev/dag0
describes the DAG device present at /dev/dag0. int:eth0
is the URI for the Linux interface eth0.
URIs that include a filename usually accept '-' to represent stdin, e.g. erf:-
will read ERF records from stdin.
- There are three pcap formats supported by libtrace:
pcapfile
,pcapint
andpcap
. Generally you want to usepcapfile
if reading or writing pcap trace files andpcapint
if reading or writing from a live pcap interface. -
pcapfile
andpcapint
have been implemented directly within libtrace, whereaspcap
uses the libpcap API. We recommend against usingpcap
wherever possible. - Most pcap-based utilities, including tcpdump, tcptrace and snort, do not support compressed trace files so you may need to decompress the trace first. For example, "zcat foo.pcap.gz | tcpdump -r-" will do this for tcpdump.
-
pcapng
refers to the next generation pcap format that is used as the default output format by Wireshark.
- Requires the Dag API from Endace.
- Anyone experiencing problems with using DAG cards for libtrace may wish to read over our DAG Notes, which describes the libtrace DAG support in more detail.
- Supports a maximum of 4 interfaces, by convention 0 for outgoing, 1 for incoming, 2 for other, and 3 is unused.
- There is at least one traceset which is known to have an ERF type of "0", just to be annoying, libtrace attempts to account for this.
- Does NOT require the dag API to read erf (and compressed erf) traces.
- Currently supports a fast way of retrieving the timestamp of the packet from kernel space using ancillary data.
- Supports uploading bpf filters into the kernel since 3.0.5+
- Supports only incoming and outgoing direction, attempts to set other directions will fail. (3.0.3+)
- Currently the default if you just provide an interface name for the URI without explicitly defining the format.
- Provides much better performance than int:. To use, you must provide the full URI when describing the input source (e.g. "ring:eth0", rather than just "eth0").
- Supports all the same features as int:
- Requires DPDK to be installed and kernel modules to be loaded
- Better performance than int: and ring: under the correct conditions.
- Each per-packet thread is bound to a CPU core and will poll waiting for packets to arrive. This means 100% CPU on these cores.
- You can only use a single instance of the dpdk: format at a given time - that is you can listen to a single interface or write to a single interface but not both.
- As of libtrace 4.0.16 you can open multiple DPDK interfaces within the same application, however, you still cannot open the same interface for both reading and writing.
For more information please read over the DPDK Notes, which describes the libtrace DPDK support in more detail.
- Allows use of DPDK on a virtual interface, e.g. for experimenting with DPDK without actual DPDK-compatible hardware (or having to assign interfaces to DPDK).
- "device type" refers to the name of the software driver that you want to use on your virtual interface, such as
net_pcap0
for the pcap driver ornet_tap0
for the TAP driver. - "device name" is the name of the virtual device you want to capture packets from (or write packets to). This interface must already exist on your system as a
veth
interface. See https://github.com/LibtraceTeam/libtrace/blob/master/test/netns-env.sh for an example on how to create virtual devices on Linux.
- Currently supports capture, but not writing.
- libtrace does not (yet?) support RT output.
- The protocol specification may eventually be made available so people can write their own servers.
- libtrace does not support nDAG output.
- This format is designed to receive ERF records over a network from a host running an nDAG multicaster (such as the tracemcast tool).
- nDAG works best when used with the parallel API.
- Capture only, no output support.
- This format allows users to use a DPDK-capable interface to intercept and decode ERF records being exported by an nDAG multicaster.
- Capture only, no output support.
- This format is designed to receive ERF records over a network from a host running the traceucast tool.
- When reading, the host and port refer to the interface and port that you want to listen on for TZSP-encapsulated packets.
- When writing, the host and port refer to the TZSP listener that you want to transmit the encapsulated packets to.
- When reading, Libtrace will try to locate its eBPF program and automatically load it. If it cannot be found the default Libbpf eBPF program will be loaded. Libtrace allows for a user to supply an eBPF program if required, this can be loaded using the URI xdp:ebpf_file:ebpf_program:<interface>
- When writing, Libtrace only accepts the URI xdp:<interface>
- Simultaneous reading and writing from the same interface with XDP is not supported.
For more information please read over the XDP Notes, which describes the libtrace XDP support in more detail.
- When writing, this format only supports conversion from
etsilive:
inputs, i.e. it cannot convert a pcap to valid ETSI encoded records. - The format portion of the URI must ALWAYS be provided, i.e.
etsifile:<filename>
, not just<filename>
- Intended for receiving LI handovers produced by OpenLI (https://openli.nz), but in theory should work with any other ETSI-compliant LI system.
- Libtrace will listen on the provided IP address and port for a TCP connection from the LI mediation function.
- Will respond to keep-alive messages from the mediator.