Questions about payload buffers in argus

[Carter Bullard]

Control plane traffic is stuff like ICMP, DHCP, and routing protocols, stuff that controls the network.

I'm sure that I'm using some stack memory to do something stupid and 4355 corrupts something important
I'm not going to be able to look at this until Mon, but I'll check it out then.

The -1 may not allocate a fixed min size for the output.

Carter

On Apr 7, 2011, at 5:41 PM, dn1nj4 <dn1nj4 at gmail.com> wrote:

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