Questions about payload buffers in argus

[dn1nj4]

Thanks Carter.

Stupid question... What's "control plane traffic"?

Sample file ftp'd to incoming/buffer_fault.bin.  There's nothing special
about this particular pcap.  It's just the first file I grabbed.  I can
consistently duplicate the problem on CentOS.  The argus file was
generated with:

argus -r <file.cap> -w <file.bin> -U 65535

I have confirmed the resulting seg fault can be generated in 3.0.0 -
3.0.4.1 by reading the file back in with:

ra -r <file.bin> -s +suser:4335

(but 4334 seems to work ok).  +duser demonstrates identical behavior at
4335/6 (one byte higher??)

As a side note, when I was trying to figure out if I could do full
buffer capturing, I tried "-U -1" which oddly works, but provides a
slightly smaller argus file than when using 65535...

Thanks for all your help.
dn


On 4/7/2011 1:02 PM, Carter Bullard wrote:
> Oh Digital Ninja,
> Sorry for the delay, I was at the CERIAS Symposium at Purdue University.
> Some very interesting things going on there.
>
> OK, there are several answers to this question.  The largest argus record
> can be 65536 bytes long including the header.  Argus records are composed
> of a 4 byte header, and then a collection of Argus DSRs.  The DSR format allows
> for sub sections of an argus record to be larger than 64K, but largest size of a
> DSR is 65532 bytes in length.  The ArgusDataStruct, which holds
> the user data buffers, can take up most of that space, but because there are
> other DSRs that will be in the record, time, flow key identifiers, metrics, etc...
> a practical limit could be considered to be around 24K for both the source and
> destination capture buffers.
>
> Argus will collect up to the configured amount of user data, during each
> ARGUS_FLOW_STATUS_INTERVAL.  So if you want to do all payload capture,
> you will want to have a large user buffer, and a small ARGUS_FLOW_STATUS_INTERVAL.
> The interval can be a fraction of a second, if that is useful.
>
> If you are interested in full packet capture for control plane information, but not
> for other traffic, consider the "-C" option.  It will capture everything for some protocols,
> and the ARGUS_CAPTURE_DATA_LEN for other traffic.
>
> Seems to me, you have a bug when you go higher than 4335 bytes.
> I'll look into it.   If you can share a data file that replicates the bug, that will
> save me a lot of time.
>
> For output formats, we support "hex", "ascii", "encode32", and "encode64"
> formats.  Use the "-M [hex | ascii | encode32 | encode64] to set the format.
>
> If you have any problems, send email !!!!
>
> Carter
>
> On Apr 7, 2011, at 12:12 PM, Digital Ninja wrote:
>
>> Hello again list,  I've not seen any responses on this request from
>> last week.  Is anyone using argus with payload buffers?
>>
>> On Thu, Mar 31, 2011 at 1:00 PM, Digital Ninja <dn1nj4 at gmail.com> wrote:
>>> Hi list,
>>>
>>> When leveraging the argus -U option to capture user buffers, what is
>>> the maximum amount of data that can be captured?  Is there a way to
>>> store all payload information?
>>>
>>> Second, when reading the user buffers back in, with ra -s +suser:XXXX,
>>> has anyone experienced a segfault?  If I set XXXX to 4334 I get all of
>>> the expected user buffers.  If however, I up that number to 4335 or
>>> higher, I get a seg fault.  Ideally I'd like to see the entire buffer,
>>> regardless of length.
>>>
>>> Finally, are the user buffers printed out in binary format or are they
>>> converted to straight ASCII (where all non-printable ASCII characters
>>> are simply ".")?  If the latter, how can one get the actual hex values
>>> from the buffers?
>>>
>>> I am currently testing with v3.0.4.
>>>
>>> Thanks in advance.