8. Troubleshooting
8.1 When compiling on a LINUX system, I get errors involving bool. How do I fix these?
This is caused by conflicts between LINUX headers and particular
versions of gcc. To fix it, set the environment variable CXX to
the name of a modern (e.g., gnu 2.95 or later) C++ compiler, or to "false"
if you don't have one, and re-run ./configure,
make, and make install in the top directory.
8.2 I get compile errors in libsrc/crl involving _crypt_struct, _off64_t, etc. How do I fix these?
This is apparently due to a bug in perl 5.8.0, which is fixed in 5.8.2, but reintroduced in 5.8.3. CoralReef 3.7.4 contains a workaround for this. You may also be able to get around it by setting the environment variable CPPFLAGS="-D_GNU_SOURCE" when running configure in coral.
8.3 CoralReef won't compile with gcc 2.96. How do I fix this?
gcc 2.96 is NOT an official release, and we do not support it. See https://gcc.gnu.org/gcc-2.96.html for more details.
8.4 How do I fix compile errors involving PAnonymizer?
If you do not need the anonymizing features, you can disable them by using
the --disable-cryptopan option to ./configure,
which will avoid the compiler errors.
In any case, please report the compiler error messages to
coral-bugs@caida.org.
8.5 The Perl applications complain about undefined symbols. How do I fix this?
A runtime error message like this:
Can't load '/usr/local/Coral/lib/Coral.so' for module Coral:
/usr/local/Coral/lib/Coral.so: Undefined symbol
"__eprintf" at /usr/libdata/perl/5.00503/DynaLoader.pm
line 169.
may be caused by using a different version of the C compiler or C
libraries to compile Coral.so or ASFunc.so than
was used to compile Perl. If your perl is newer than your compiler,
then simply rebuilding CoralReef should fix this problem.
If not, edit perl.inc in the
top directory to set the variable PERL_LD to the name of the C
compiler that was used to compile Perl, and run make
clean and make install in the top directory. If
that compiler is no longer available, you may need to reinstall
Perl or the C libraries.
8.6 Why do the cell timestamps jump backward in my POINT trace? Why do some applications report intervals with negative duration?
Apparently there is a race condition in the card or driver between clock reset and beginning to capture data, causing a single backward jump a few hundred microseconds into a trace. In applications that report intervals, this problem can manifest itself as a negative duration in the first interval. This appears to affect both OC3 and OC12 point cards.
In CoralReef release
3.5, libcoral and most CoralReef applications will by default
discard cells read before the clock reset, avoiding the problem.
In earlier versions, you can use the application
crl_time
to find problems like this, and
crl_cut
to chop off the first few dozen bad cells.
8.7 Why do the cell timestamps jump backward in my FATM trace?
There appears to be a race condition in the FATM card between incrementing the high order clock when the low order clock wraps, and capturing more cells. This occasionally causes the timestamps to jump backwards a little less than 0.00262144 seconds when the low clock wraps, and then forward again by a little more than 0.00262144 seconds when the high clock catches up. (The period of the low clock wrap is 0.00262144 seconds.)
By default, libcoral and most CoralReef applications will attempt
to compensate for this problem by incrementing the high clock when
the low clock wraps, and then ignoring the next high clock
increment reported by the driver. However,
crl_trace and
crl_encode
do not perform this correction, so trace files will contain raw
uncorrected data. Most other applications perform the correction
when they read the trace.
8.8 Why does the point card sometimes report -185273100 or -454761244 cells lost?
This was due to a bug in older versions of the CoralReef POINT driver. It was fixed in version 3.3.2.
8.9 Why does running some Coral applications appear to cause cell/packet loss when the applications are run for a short durations?
Coral devices return their data to CoralReef in blocks of integral
ATM cells (for FATM/Point cards blocks are 17545 cells and for DAG
cards blocks are 16384 cells.) Normally, they do not return any
data until a block fills up. When capturing one cell per packet (as
crl_flow and
crl_rate
do), this means 17545 or 16384 cells must
go by before the Coral device will give them to CoralReef. When an
interval ends in realtime, CoralReef can not process the interval
yet because it must assume the card is still holding a block
containing packets belonging to that interval. So it waits for the
card to fill up the block and give it to CoralReef. Only then can
CoralReef look at the cell/packet timestamps and assign the delayed
packets to the interval to which they belong. If the traffic rate
is low, filling the block may take a long time, perhaps even
multiple intervals. When the block finally fills, CoralReef reads
it, and processes data for packets belonging to all intervals
contained in the block. So, for example, if you use 10s intervals
and you see pauses of 50s, and then output
for 5 intervals all at once, it is because your traffic takes 50s
to fill a block (e.g. 16384 packets in 50s, or 328 packets per
second).
The only time the card will return a block before it is filled is when CoralReef stops the card, which it does when the duration ( -Cd) expires in realtime. So it will always be able to process data at the end of the duration, regardless of how full the last block is.
If you run applications like
crl_flow
repeatedly with 10s duration
instead of once with infinite duration and 10s intervals, you will
get reports approximately every 10s. But since that requires
stopping the card and restarting it, you will also miss packets
during the down time.
8.10 Why do CoralReef applications crash the first time one is run on a DAG card?
This was due to an incompatibility between old DAG drivers (earlier than 2.2.1d?) and CoralReef. We recommend you upgrade your DAG drivers.
8.11 Why does the report generator t2_report[++] report a large number of Autonomous Systems (AS's) as unknown?
ASFinder requires a current BGP table in order to perform the conversion from IP address to AS. This table must be kept current. See the answer to How can I convert an IP address into an AS (Autonomous System) number? and the documentation for ASFinder for more information.
8.12 Why doesn't my pcap filter expression match any packets on my VLAN?
Due to a bug in libpcap-0.6.2, you must specify the vlan iomode option on VLAN sources, or operations on layer 3 and above will not work. We hope this will be fixed in a future version of libpcap.
8.13 Why do I get "no support for coral_type=-2" when reading a native interface (or "-1" when reading a tcpdump file)?
A suitable version of libpcap was not found when you installed CoralReef. You should make sure libpcap is installed, and then reconfigure CoralReef. If libpcap is not in a standard location, you will need to use the --with-inclibdirs option when configuring CoralReef (see the INSTALL file).
8.14 "Warning: BPF filter on interface 0 will run in user space, not in kernel."
To support BPF filtering on linux systems, the CONFIG_PACKET kernel option must be enabled, and for best performance the CONFIG_FILTER kernel option should also be enabled (for more information, see "README.linux" in the libpcap documentation, and "Configure.help" in the linux kernel documentation).
8.15 Why do I get "Warning: Must use positive value to set FlowCounter's bytes" when reading t2-format data with CAIDA::Tables reading functions?
Assuming the input is not in fact corrupted or otherwise invalid, this is caused by an apparent bug in the 'perlio' layer in newer versions of perl. The CAIDA::Traffic2::FileReader module attempts to automatically change this layer in order to facilitate proper reading. If you aren't using FileReader (ie, calling CAIDA::Tables reading functions directly), setting the environmental variable PERLIO to 'stdio' should prevent this problem.
Next Previous Contents