argus crash problem

[Lei Wei]

Thanks a lot Peter!
I ran the ra again and splitted the source and dest. I can see that 
there are packets in both directions in one record entry. For the many 
connections with unknown directions, I have a question about how argus 
works. Does argus record a connection and count the number of packets 
in it within a small time period? For example, maybe in 1ms, it records 
all the seen connections? If so, it sort of makes sense that the 
already established connections have unknown directions because if 
argus can see packets from both directions within this 1ms, there's no 
single direction in this connection at this point. But for syn and fin 
it definitely have single direction. Before I took a closer look at the 
flow data, I thought argus would record by a transaction basis, i.e. 
one full tcp transaction per entry. But since it is not the case, I 
wonder if it works as I'm thinking now.

Thanks.
Lei


Quoting Peter Van Epp <vanepp at sfu.ca>:

> On Wed, Jan 30, 2008 at 06:30:23PM -0500, Lei Wei wrote:
>> Hi Carter,
>>
>> I'll do what you suggested. But I don't quite understand "You should
>> print both spkts and dpkts". what does "spkts" mean and How do I do
>> that?  And by the way, is it normal that I got so many connections with
>> unknown directions?
>>
>> Thanks.
>> Lei
>>
>
> 	By default (a change from the previous norm) ra is printing the
> sum of both packets and bytes. To split them out use either the -s command
> on the command line (as in):
>
> ra -r file -s stime flgs proto saddr sport dir daddr dport spkts 
> dpkts sbytes dbytes state
>
> 	or put an equivalant line in your .rarc file. This prints source and
> dest packets and bytes as separate counts.
> 	Given the speed of your link I expect the best thing you can do (if
> you haven't already) is run argus and archiving on separate boxes. On the
> box with the dag:
>
> argus -d -P 560 -i eth0 -i eth1 -F /scratch/argus.conf
>
> (where argus.conf =
>
> ARGUS_COLLECTOR=no
>
> 	This writes the argus records to a socket and does no disk I/O on the
> capture host which minimizes bus contention (and you sound like you need all
> you've got for network traffic :-)). The data collection occurs on another
> machine that shares a network with the collector via:
>
> ra -S collector_ip:560 -n -w /var/log/argus/com_argus
>
> this instance reads the argus data from the network connection to the sensor
> and writes it to disk on the local machine (so the disk I/O isn't interfering
> with data collection). You probably also want to run argusarchive from cron
> every 10 minutes (or perhaps even less) to archive the data files so 
> they don't
> become so large. There are better ways to structure the ra capture (if you
> look back in the list archive you will find Carter's suggested setup for
> reliable data collection, I just haven't gotten as far as 
> implementing it yet).
> 	That may reduce the load on your collector box enough to make it work
> better.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>