[ARGUS] Malfunctioning of argus -S option for some pcaps

[Hang Guo]

Thanks Carter, that saves life!!!!

Could you help me understand one more bit about -S option: when implemting
this report interval (-S), I guess argus uses one timer for all flows
instead of a seperate timer for each flow right?

Thanks,
-Hang

On Tue, Jul 2, 2019 at 6:28 PM <carter at qosient.com> wrote:

> Hey Hang,
> The problem is that your packets are not in time order, so argus is doing
> the right thing.  Best example is around packet # 3848, where the packet
> timestamps jumps back 6.5 hours.  Nothing argus can do with that but tally
> the packets … and all the flows will be messed up for a little while, until
> the packet timestamps move ahead in front of the largest startime.  If you
> can get the packets sorted in time, then things should work fine.
>
> Carter
>
> On Jul 2, 2019, at 4:19 PM, Hang Guo <hangguo at usc.edu> wrote:
>
> Hi,
>
> I found argus -S option malfunctioning for some pcaps. For example, when
> running argus -S 10 with the pcap attached (MAC and IP anamoyzed, payload
> dropped for privacy), instead of reportting every 5-tuple flows every 10
> seconds, duration of some reported 5-tuple flows (as pasted below) are
> hundreds of seconds. Just wonder what is the possible cause and is there a
> fix to this?
>
> argus -S 10 -r dur_test_anon.pcapng -w - | ra -c "," -r - -s dur | sort
>> -nr | head -5
>> 4865.550781
>> 296.601562
>> 296.393066
>> 294.411255
>> 292.840790
>
>
> Thanks,
> -Hang
> <dur_test_anon.pcapng>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20190702/c0c2f352/attachment.html>