argus option review
Carter Bullard
carter at qosient.com
Sun Jan 28 10:26:37 EST 2001
Hey Peter,
I should make this error message bit more informative,
like what port is it trying to bind to. You are correct,
the acutal enforcement of the option defaults will be in
"V".
Hmmm, I get byte counts for ECHO traffic that are > 0.
So lets fix this. How are you running argus?
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter at qosient.com
Phone +1 212 813-9426
Fax +1 212 813-9426
> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
> Sent: Sunday, January 28, 2001 12:36 AM
> To: argus
> Subject: Re: argus option review
>
>
> >
> > Gentle people,
> > Ok below is the updated argus() usage, (just one change for
> > the default port value). A few more defaults to discuss.
> >
> > Argus Version 2.0
> > usage: argus [options] [-i interface] [filter-expression]
> > usage: argus [options] -r packetfile [filter-expression]
> >
> > options: -b dump filter compiler output.
> > -d run Argus in daemon mode.
> > -D <level> set debug reporting <level>.
> > -e <value> specify Argus Identifier <value>.
> > -h print help.
> > -F <conffile> read configuration from <conffile>.
> > -J generate packet performance data.
> > -M <secs> set MAR Status Report Time Interval
> > (300s).
> > -m turn off MAC Layer Reporting.
> > -O turn off filter optimizer.
> > -p don't go into promiscuous mode.
> > -P <portnum> enable remote access on <portnum>.
>
> Is it correct to assume this isn't disabled by default
> in argus-2.0.0U?
> I'm running a test copy beside a copy of 1.8.1 and when I
> start the 2.0 one
> without a -P option I get a socket bind error (which I'm
> assuming is the output
> port):
>
> ids# ./argus_bpf -w t &
> [1] 1375
> ids# argus_bpf[1375]: started
>
> argus_bpf[1375]: argus_bpf: ArgusEstablishListen: bind() error
>
> [1] Done ./argus_bpf -w t
>
> * this is the 1.8.1 version with no -P0 in place *
>
> ids# ps auxw | grep argus
> root 277 0.0 1.8 4996 4604 p0- S 4:42PM 2:36.16
> /usr/local/bin/arg
> us_bpf -i fxp0 -w -
>
>
> ids# ./argus_bpf -P0 -w t &
> [1] 1378
> ids# argus_bpf[1378]: started
>
>
> ids# kill -HUP 1378
>
> Setting -P0 on 2.0.0U clears the error message.
>
> > -R generate response time data.
> > -S <secs> set FAR Status Report Time
> Interval (60s).
> > -w <file ["filter"]> write output to <file>, or '-', for
> > stdout,
> > against optional filter expression.
> > -X reset argus configuration.
> >
> > The -D option is not printed if argus wasn't compiled with the
> > ARGUS_DEBUG option set.
> >
> > The -e option. Should the default for the ArgusID be 0? Right now
> > its the magic cookie that we use for the argus stream.
>
> That seems a reasonable default to me. It would
> presumably allow the
> data stream to be correlated with which (of potentially
> several) argi the
> data came from.
>
> >
> > The -m option. Should we capture MAC addresses by default?
> > This adds 20 bytes to each record.
> >
>
> I'd vote for off by default. In my case there are two
> routers on the
> argus link and the MACs are uninteresting. As long as it is
> turn offable though
> I'm easy.
>
> > The -M option. Should the default MAR status record interval
> > be 300 seconds? This can be used by clients as a KEEP_ALIVE
> > and it gives decent aggregate link stats. This could be 60 seconds.
> >
>
> Haven't played enough yet to have an opinion on these two.
>
> > The -S option. Should this default to 60 seconds for flow status
> > reports? This seems like a good value but it could go to 30 or 10
> > for that matter. 10 may increase the number of records you get
> > depending on the type of traffic you get.
> >
> > Carter
> >
>
> Now for the possibly bad part: I was poking at icmp
> checking to make
> sure I get byte counts on ICMP packets and see a few
> anomolies (some due to
> forgetting the "./" and using the 1.8.1 ra :-) ) or I haven't
> set the flags
> right:
>
> ./ra -r argus.log -c -n -a
> 27 Jan 01 20:55:22 man version=2.0 probeid=0
> STA
> 27 Jan 01 20:55:22 icmp 192.75.245.2 <->
> 209.87.31.2 1
> 1 0 0 ECO
> 27 Jan 01 20:55:23 icmp 209.87.57.154 <->
> 142.58.200.82 1
> 1 0 0 ECO
> 27 Jan 01 20:55:23 icmp 192.75.245.2 <->
> 142.58.12.68 1
> 1 0 0 ECO
>
> All the byte counts appear to be 0. I thought the
> default was byte
> counts for the whole packet (including headers) with a switch
> to fall back to
> the 1.8 mode of only the data portion of the packet. Did that
> change while
> I wasn't around (I don't see such a switch in the option list)?
> I've also verified that the bpf fix isn't in FreeBSD
> 4.2-RELEASE (I
> haven't looked at current) so the patch I sent to the list
> needs to be applied
> on FreeBSD boxes. I'll look at the status of OpenBSD (I
> expect it may be fixed
> in the CVS version, if a new release of 2.7 hasn't happened yet).
> Hopefully I'll get to putting up a test machine that I can send
> controlled data to using tcpreplay next week to check out the
> byte count
> stuff (I remember verifying it was right in an early 2.0
> release, but perhaps
> not with ICMP records).
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3699 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010128/a6d0e0ee/attachment.bin>
More information about the argus
mailing list