Problems with racluster

[Rafael Barbosa]

Hi Carter,

Nice. The scenario 1 is exactly what I need. Although the patch still does
not work for me, using the 300s idle timeout, I get only one record:

$> ~/workspace/argus-clients-3.0.7.1-patch2/bin/racluster -r f1.argus
f2.argus -f racluster.conf
         StartTime      Flgs  Proto            SrcAddr  Sport   Dir
   DstAddr  Dport  TotPkts   TotBytes State
   21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        46      13676   FIN
$> cat racluster.conf
filter="" status=0 idle=300

However, if I change it to 60s, I get the two records I expected:

$> ~/workspace/argus-clients-3.0.7.1-patch2/bin/racluster -r f1.argus
f2.argus -f racluster.conf
         StartTime      Flgs  Proto            SrcAddr  Sport   Dir
   DstAddr  Dport  TotPkts   TotBytes State
   21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        23       6838   FIN
   21:11:52.493919  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        23       6838   FIN
$> cat racluster.conf
filter="" status=0 idle=60


Best regards,
Rafael Barbosa
http://www.ewi.utwente.nl/~barbosarr/



On Mon, Sep 10, 2012 at 2:07 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Rafael,
> We should be generating your scenario #1.  You have a racluster.conf file
> that sets
> an idle timeout value for all flows.  Because of that idle timer, you
> should get 2 flow
> status records, that represent the flow's activity between the idle
> timeout period.
>
> The last version of racluster.c obviously needs one last tweek.  Could you
> please try this one?
> This has one line changed, where we move the call to ArgusClientTimeout()
> to the
> received flow status record logic, rather than any record received.
>
> Carter
>
>
>
> On Sep 10, 2012, at 5:50 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:
>
> Hi Carter,
>
> The new patch seems to solve the problem with the port0 test case, and I
> did not see any records with a reversed direction.
>
> However, I still do not understand the output for the first test, with
> files f1 and f2:
> $> ra -r f1.argus
>    21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
> 172.31.1.100.10500        22       6772   FIN
> $> ra -r f2.argus
>    21:09:30.971095  e           tcp       172.31.1.100.10500     ?>
> 172.31.1.102.61722         1         66   CON
>    21:11:52.493919  e *         tcp       172.31.1.102.61722     ->
> 172.31.1.100.10500        23       6838   FIN
> $> ~/workspace/argus-clients-3.0.7.1-patch2/bin/racluster -r f1.argus
> f2.argus -f racluster.conf
>          StartTime      Flgs  Proto            SrcAddr  Sport   Dir
>      DstAddr  Dport  TotPkts   TotBytes State
>    21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
> 172.31.1.100.10500        22       6772   FIN
>    21:11:52.493919  e *         tcp       172.31.1.102.61722     ->
> 172.31.1.100.10500        24       6904   FIN
>
> I see 3 possible outputs:
>
> 1 - The first record in f2.argus is aggregated back to the record in
> f1.argus. The output is two records with the same TotPkts/TotBytes. In this
> case, each TCP connection becomes a separated record, which is what I
> wanted.
>
> 2 - The first record in f2.argus is aggregated to the second record in
> f2.argus. The time stamp would be the one of first record in f2.argus. This
> is seems to be what racluster is doing, however the timestamp is not
> updated.
>
> 3 - The records are not aggregated at all. The first record f2.argus does
> not aggregate back to the record in f1.argus because this record is marked
> as "FIN", and does not aggregate to the second record in f2.argus because
> the connection wasn't open yet.
>
> Could you explain how the aggregation is being done?
>
> Thanks,
> Rafael Barbosa
> http://www.ewi.utwente.nl/~barbosarr/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120910/66dd341e/attachment.html>