Misc problems with argus-clients v. 3.0.5.34

[Markku Parviainen]

Hi,

I'm reporting some bugs and (annoying) features in argus-clients
version 3.0.5.34. The host is 64bit linux, gcc 4.1.2, kernel 2.6.18.


1. Aborting rabins/racluster with ctrl+c

There's a feature at least in racluster and rabins that I would want
to be removed: aborting the command with ctrl+c does not always work,
especially when the process is becoming a memory hog. Please fix it so
that ctrl+c would always instantly abort whatever the command was
doing, trashing everything from the memory without printing anything
it didn't had time to. Now it seems that it receives the command, but
ignores it while doing "just one more thing for next 5 minutes".
Sometimes when racluster starts outputting lines to console and I
can't stop it with ctrl+c at all.
Now I typically have to stop the process with ctrl+z and then kill it
with kill -9 %2, or similar. That works, but kinda sucks.



2. Segmentation fault when writing to a protected directory

All argus clients crash with Segmentation fault when trying to write
to a file (i.e. create it) in a directory where the current user has
no write permission.

$ ra -D6 -r t.arg -w t2.arg
...
ra[23826.e025c773a62b0000]: 2012-02-28T11:54:22 ArgusReadFileStream() starting
ra[23826.e025c773a62b0000]: 2012-02-28T11:54:22 ArgusReadStreamSocket
(0x2ba673db6010) read 600 bytes
ra[23826.e025c773a62b0000]: 2012-02-28T11:54:22 ArgusGenerateRecord
(0x2ba673db6620, 0) len 200
Segmentation fault



3. Wrong packet counts from rabins

Rabins reports wrong and somewhat random packet counts. It is expected
that rabins averages the values, but the sum of packets should not
change. Am I doing something wrong here?
I tried pre-sorting the data by stime, but it does not help on all
cases, depending on the size of the time bins.
And as it seems, when the file was written by argus and then grouped
by racluster (with -m saddr daddr proto dport), the file typically is
not ordered by stime on disk. The test file here (t.arg) contains data
for one hour, and obviously, is not changed in the middle:

This is correct:
$ racluster -m proto dport -r t.arg -s proto dport pkts -n - 'tcp and
dst port (0 or 80 or 22)'
   tcp 0          8903
   tcp 22         1640
   tcp 80       136659

The same directly with rabins causes garbage:
$ rabins -m proto dport -M hard time 5m -r t.arg -w - - 'tcp and dst
port (0 or 80 or 22)' | racluster -m proto dport -s proto dport pkts
-n
   tcp 0          2001
   tcp 22           88
   tcp 80        29865

Pre-sorting fixes the problem here:
$ rasort -m stime -r t.arg -w - - 'tcp and dst port (0 or 80 or 22)' |
rabins -m proto dport -M hard time 5m -w - | racluster -m proto dport
-s proto dport pkts -n
   tcp 0          8903
   tcp 22         1640
   tcp 80       136659

But not here when using 5s bins:
$ rasort -m stime -r t.arg -w - - 'tcp and dst port (0 or 80 or 22)' |
rabins -m proto dport -M hard time 5s -w - | racluster -m proto dport
-s proto dport pkts -n
   tcp 0          9378
   tcp 22         1165
   tcp 80       136659


What's even more odd here is that another racluster in chain changes
the values again.
This is correct as it should be:
$ racluster -m saddr daddr proto dport -r t.arg -w - - 'tcp and dst
port (0 or 80 or 22)' | rasort -m stime  -w - | rabins -m proto dport
-M hard time 5m -w - | racluster -m proto dport -s proto dport pkts -n
   tcp 0          8903
   tcp 22         1640
   tcp 80       136659

But this is not. The values are not even the same as with 5s bins before.
$ racluster -m saddr daddr proto dport -r t.arg -w - - 'tcp and dst
port (0 or 80 or 22)' | rasort -m stime  -w - | rabins -m proto dport
-M hard time 5s -w - | racluster -m proto dport -s proto dport pkts -n
   tcp 0          9882
   tcp 22          661
   tcp 80       136659

Random results makes a network analyst very frustrated...