Argus 2.0 User Payload Data

[Chas DiFatta]

I agree,

In proposal number one, 32 bytes is not enough, especially when
you're observing protocols that tend to have a lengthy header
such as HTTP.  While I do find printing the first packet of
the source/destination data useful,

ra -nQ 64 -s localhost

Fri 07/14 17:24:34  M  tcp 24.251.8.29.24610  ->  128.2.17.34.80   CLO  GET
/something_good.asp?foo=0&bar=1	500

I agree with Peter, number 2 gives the most flexibility, but I
don't want to lose sight of some options that can provide value
quickly. Yes, keeping up with the data stream will require some
horsepower, but it's worth it.  Triggering on the contents of the
packet of the destination host is useful as well.  I.e. from the
above ra output, knowing that the return code is a "500" tells much.

Proposal number 2 could be used to "profile" the flow of applications,
which in tern could provide a "signature" for an applications QOS.
I vote for option number 2...

	...cd

>
> 	I'd lean towards option 2 as well. It provides the most flexability
> for being able to do things like capture the entire packet when a flag
> oddity (as a for instance) shows up or fragments that have different /
> overlapping offsets appear in the input stream without necessarily always
> keeping the entire packet. The down side is that it requires more
> horsepower
> to keep up with the data stream, but power is getting cheaper by the day.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada