FAQ

I have a DAG card but libtrace is not detecting it during the configuration stage?

You can manually specify where your DAG libraries are located by using the --with-dag=DIR option for ./configure. DIR needs to be the location you installed the DAG software to, not the location of the DAG device e.g. DIR might be /usr/local/dag not /dev/dag0. More recent DAG drivers (DAG 2.5 or later) will typically install to /usr/local/lib and libtrace will search there by default. DAG 2.4 drivers tend to install less cleanly so the location of the DAG source code should be specified using --with-dag to help libtrace locate the required libraries and header files.

I'm encountering bizarre assert failures (e.g. "invalid ERF type" or "not a pcap trace") when I try to read a trace

If you have built an older version of libtrace without zlib support, libtrace cannot read compressed trace files properly and will produce some unexpected errors.

tcpdump can't read the pcap traces I created with libtrace!

By default, some libtrace tools (such as traceconvert) write output traces as compressed files which tcpdump can't natively read. Use tcpdump -r <(zcat mytrace.pcap.gz) to read these traces.

libtrace doesn't understand header type x!

If you are trying to use libtrace to understand a header which libtrace doesn't natively support then you can use trace_get_layer2 to get a pointer to the link layer (or some suitable other header), use the trace_get_payload_from functions to skip past any extra headers you might need to, then take the result and cast it to a structure describing the layout of the problematic header.

Alternatively, send us an email suggesting that support for header x be added to libtrace :)

I get a lot of errors stating "ERROR: No debug map or DWARF data was found to link." when building on Mac OS X!

This appears to be a bug in the dwarfutils - try upgrading Xcode to version 2.5 or later.

When using libtrace 3.0.7 or 3.0.8, I get a segmentation fault whenever I try to read a trace file!

There appears to be a nasty threading bug that can crop up when libtrace is built with optimisations on a 32-bit system. This has been fixed since libtrace 3.0.9 -- if you're having this problem, upgrade to a more recent version of libtrace.