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
make install in the top directory.
_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.
gcc 2.96 is NOT an official release, and we do not support it. See http://gcc.gnu.org/gcc-2.96.html for more details.
If you do not need the anonymizing features, you can disable them by using
--disable-cryptopan option to
which will avoid the compiler errors.
In any case, please report the compiler error messages to
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
may be caused by using a different version of the C compiler or C
libraries to compile
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 install in the top directory. If
that compiler is no longer available, you may need to reinstall
Perl or the C libraries.
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
to find problems like this, and
to chop off the first few dozen bad cells.
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,
do not perform this correction, so trace files will contain raw
uncorrected data. Most other applications perform the correction
when they read the trace.
This was due to a bug in older versions of the CoralReef POINT driver. It was fixed in version 3.3.2.
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
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
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
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.
This was due to an incompatibility between old DAG drivers (earlier than 2.2.1d?) and CoralReef. We recommend you upgrade your DAG drivers.
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.
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.
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).
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).
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.