argus option review

[Peter Van Epp]

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