argus 3.0 bloating on OpenBSD 4.3

[Peter Van Epp]

On Mon, Jan 26, 2009 at 11:33:09PM -0800, Michael Sanderson wrote:
> I'm seeing similar things to what Martijn van Oosterhout had with his
> Linux machine, though on OpenBSD 4.3.
> 
> I'm running argus 3.0 on a 32-bit OpenBSD 4.3 machine, with an ra
> collecting data on a 32-bit OpenSuSE box.  Neither is running a
> customized kernel.  Argus does not appear to be built with threads on
> the OpenBSD box.  Upon occassion, the argus will output error lines like
> 
>  ArgusInterface timestamps wayyy out of order: now -732332471 then
> 1233017300
>  ArgusInterface timestamps wayyy out of order: now -1504018871 then
> 1233017510
> 
<snip?>

	The error message print routine is likely incorrect in that it is 
displaying a signed timet value (which should be unsigned). That said the
time stamp would appear to be very incorrect which will be a problem. The
second stamp looks correct:

./timet.pl 1233017510
Mon Jan 26 16:51:50 Canada/Pacific 2009

the first one will have the MSB set to be appearing negative and thus way out
of range (somewhere up in 2038 as I recall at 32 bits). I'd suggest (hardware
and link speed willing :-)) turning on 

ARGUS_PACKET_CAPTURE_FILE="/var/log/argus/packet.out"

in an argus.rc file. That will caputure the incoming pcap data (at the cost of
local disk I/O on the sensor machine which may cause packet loss and/or disk
space issues). The idea is to see if the pcap timestamps are jumping wildly.
If this is a multiprocessor machine perhaps due to the same issue Martijn saw.
While I didn't look very far in to that bug, it looked to be CPU cache related
and thus could be OS agnostic if the other systems haven't encountered it yet.
That would suggest ane option would be a SUSE sensor with a kernel later than
the fix for the problem (which has the added bonus of allowing Phil Wood's
mmap libpcap libs to be used for additional speed :-)). If the incoming pcap 
timestamps aren't correct there isn't going to be much that argus can 
do about it I don't think. The OS needs to be fixed or a DAG (with internal 
time stamping enabled which just avoids the problem :-)) would be needed. 
 
Peter Van Epp