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/dag 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 libtrace without zlib support, libtrace cannot read compressed trace files properly and will produce some unexpected errors. The best solution is to install zlib-dev and re-install libtrace.

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

By default, pcapfile: outputs compressed pcap traces 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 getlink to get a pointer to the link layer (or some suitable other header), and then use trace_get_payload_from_header to skip past any extra headers you might need to (for example vlan headers), then take the result and cast it to a structure representing your preferred header.

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 gcc 4.4.1 (which is the packaged version on many Ubuntu systems).

• The best possible fix (until libtrace 3.0.9 is released) is to make the change described in r1681 and re-build libtrace. Obviously this will involve editing the libtrace source code but will fix the problem without impacting on performance.
• An alternative is to disable threaded IO by running 'export LIBTRACEIO=nothreads' in the terminal which you are using to run the failing libtrace program. This will disable threaded IO, which will make the trace processing slower.
• You could also disable optimisations by adding 'CFLAGS="-g -O0"' when running ./configure - this will mean that you can still use threaded IO but the entirety of libtrace will be unoptimised.