Version 11 (modified by salcock, 10 years ago) (diff) |
---|
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.