Problems with "-n" option

Rafael Barbosa rrbarbosa at gmail.com
Wed Sep 29 08:41:56 EDT 2010


Hi,

I understand that depending on the information used in the filter my results
can change depending in the "-n" option.
However in the example I sent, two flows have their saddr, daddr exchanged
depending if the "-n" option is used. No filters used. Is that an expected
behavior?

Rafael Barbosa
http://www.vf.utwente.nl/~barbosarr/



On Fri, Sep 24, 2010 at 7:56 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Rafael,
> It is possible that the issue is in your filter, rather than the direction
> of the flows.
> ra* programs will use name resolution to see what to use when composing the
> filter. So, if you provide names or addresses in your filter, the argus
> compiler
> will try to grab all the addresses returned by bind for that string and
> create
> filter entries for all the returned addresses.
>
> When you provide a "-n" we shouldn't go to bind for resolution, and so....
> it maybe
> that the actual filter that you are creating is different depending on the
> "-n".
>
> Run ra() with the -b option, that will dump the compiler output, and we can
> then compare
> the filters when you use and don't use "-n".
>
> Carter
>
> On Sep 22, 2010, at 8:51 AM, Rafael Barbosa wrote:
>
> Hi again,
>
> Spend a while doing some tests trying to reproduce the error. Here is my
> explanation for the behavior I observed:
>
> My filter consisted in selecting a number of saddr fields (dst host X or
> dst host Y or ...). For some reason some flows have their 'saddr' and
> 'daddr' exchanged when comparing the output generated by ra() with the
> option '-n' and without it. As a consequence the amount of records displayed
> (lines counted with wc) is different, as a different number of saddr is
> displayed when using the filter.
>
> The attached file demonstrate the problem. If you run this series of
> commands you can find 2 records that have their saddr and daddr exchanged.
> So a filter which is based in saddr or daddr, would have a different effect
> depending on the use of the "-n" option.
>
> $ ra -nn -r file.argus -s saddr,daddr > withN
> $ ra -r file.argus -s saddr,daddr > withoutN
> $ diff withN withoutN
> 284c284
> <            1.0.6.1            1.0.2.1
> ---
> >            1.0.2.1            1.0.6.1
> 929c929
> <            1.0.6.1            1.0.2.1
> ---
> >            1.0.2.1            1.0.6.1
>
>
> --
> Rafael Barbosa
> http://www.vf.utwente.nl/~barbosarr/
>
>
>
> On Tue, Sep 21, 2010 at 5:39 PM, Rafael Barbosa <rrbarbosa at gmail.com>wrote:
>
>> Hi all,
>>
>> I think I discovered a bug in ra() when using the "-n" option. I while
>> trying to display the unique saddr and daddr in a argus file using ra() and
>> some bash scripting I kept getting inconsistent results. In the end
>> everything seems to boil down to the "-n" option. Basically I get a
>> different set of results for one of my files depending if this option is
>> used or not (in my understanding it should only change how the records are
>> displayed).
>>
>> For example:
>> $ ra -nn -r file.argus  -t 2009/01/22 - "some large filter" | wc -l
>> 438457
>> $ ra  -r file.argus  -t 2009/01/22 - "some large filter" | wc -l
>> 438864
>>
>> I am trying to generate some file I could share that reproduce the error,
>> but I am having some problems with it. If I try to copy the file:
>>
>> $ ra -w bug -nn -r file.argus  -t 2009/01/22 - "some large filter"
>>
>> Both "ra -r bug | wc" and "ra -r bug -nn | wc" give the same result
>> (438457), while if I try:
>>
>> $ ra -w bug -r file.argus  -t 2009/01/22 - "some large filter"
>>
>> Both "ra -r bug | wc" and "ra -r bug -nn | wc" give the same result
>> (438864).
>>
>> If I am able to generate some (anonymized) file I can share, I will post
>> it afterwards.
>> I am using version 3.0.3.17 of argus-clients.
>>
>> --
>> Rafael Barbosa
>> http://www.vf.utwente.nl/~barbosarr/
>>
>>
> <file.argus>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100929/a1b2e69f/attachment.html>


More information about the argus mailing list