Argus Client Command Line Arguments

[David Edelman]

I did a few more tests and it seem that the mid line  filter is being
recognized correctly my 64-bit on FC 18 system.

--Dave


-----Original Message-----
From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Saturday, August 10, 2013 10:02 AM
To: David Edelman
Cc: Argus
Subject: Re: Argus Client Command Line Arguments

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
> 
>