Argus Client Command Line Arguments

[David Edelman]

I was afraid that this was the case. 

I am still working my way through the book so I can't really comment other than say so far, so good. 


Dave Edelman


On Aug 10, 2013, at 10:01, Carter Bullard <carter at qosient.com> wrote:

> Hey Dave,
> I think that this is incorrect, as a single - should be end of parameters and the beginning of the filter.  But getopt() on some Linux machines is using -- as a terminating condition now, which seems new(er) and may compel us to move to a double -- in our documentation.
> 
> The real question is " does the filter work "?  On many systems
> it won't get parsed as a filter expression, as getopt() may see
> them as options to pass to the getopt() parameter parser.
> Our current logic is, anything after parsing options, pass as a filter.
> 
> So this is not as it was intended...
> So how did you like is Richard's book ???
> 
> Carter
> 
> On Aug 9, 2013, at 7:03 PM, "David Edelman" <dedelman at iname.com> wrote:
> 
>> Carter,
>> 
>> In Richard Bejtlich's new book he does include examples of using Argus and
>> some of the clients but he consistently puts the BPF filter arguments in the
>> middle of the argument string preceded by the isolated minus sign e.g.:
>> # racluster -r filename.argus - tcp  and src port 80  -s +sappbytes 
>> 
>> I just attempted to do that on one of my systems and it does work. Is this
>> intended behavior that will be supported over the long term? I had always
>> considered the isolated minus sign as terminating option string processing.
>> If it is actually a non-terminal  escape from option processing  then the
>> current use makes sense.
>> 
>> --Dave
>> 
>>