Question about states

Thu Dec 10 12:25:40 EST 2009

Hey Matt,
Found the problem.  Seems that you have a packet that is reporting a window size of
32M+ bytes, which is bigger than I expected.  My bad.  Here is a patch, and I'll include
this patch in the official argus-clients-3.0.2 release package which is now officially
frozen.

Give this patch a try, or download the newest argus-clients-3.0.2.tar.gz from the website.
http://qosient.com/argus.

Sorry for the inconvenience,

Carter

On Dec 1, 2009, at 2:31 PM, Matt Brewer wrote:

> Hi Carter,
> 
> The packets that cause the overflow are available online.  http://www.ddtek.biz/ctf_dc17_packets.tbz.torrent
> 
> If you convert the ctf_dc17.pcap000 to an Argus file then attempt to read it with RA with at least adding swin and dwin fields it will crash.  I followed the instructions provided by Peter and nothing changed the output.
> 
> ===========================
> | Matt Brewer
> | CCNA
> | www.sheridantutorials.com
> ===========================
> 
> ----- Original Message -----
> From: carter at qosient.com
> To: "Matt Brewer" <hilather at gmail.com>
> Sent: Tuesday, December 1, 2009 11:46:52 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [ARGUS] Question about states
> 
> Hey Matt,
> Need the packet file that is causing problems.
> Carter 
> Sent from my Verizon Wireless BlackBerry
> 
> -----Original Message-----
> From: Matt Brewer <hilather at gmail.com>
> Date: Fri, 27 Nov 2009 19:49:55 -0500 (GMT-05:00)
> To: Carter Bullard<carter at qosient.com>
> Subject: Re: [ARGUS] Question about states
> 
> Hi Carter,
> 
> Sorry for taking so long to reply, I've had the flu and been out of action for the last few days.  
> 
> I really like the way the -z flag works, translating the state changes to the TCP flag equivalent.  The only thing I would change would be to have lower case letters represent the source flags and uppercase represent destination flags.
> 
> Heres an example.  A TCP conversation:  
> Syn -> 
>   <- Synack
> Ack -> 
>   <-Fin
> Rst ->
> 
> Would be represented as sSFr
> 
> If its not too much to ask could you work this into a command line switch?
> 
> Also, Monday I'll be in the office again and should be able to perform the necessary debugging for the buffer overflow. 
> 
> ===========================
> | Matt Brewer
> | CCNA
> | www.sheridantutorials.com
> ===========================
> 
> ----- Original Message -----
> From: "Carter Bullard" <carter at qosient.com>
> To: "Matt Brewer" <hilather at gmail.com>
> Cc: "argus-info" <argus-info at lists.andrew.cmu.edu>
> Sent: Tuesday, November 24, 2009 11:23:31 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [ARGUS] Question about states
> 
> Hey Matt,
> In most cases, the only reason a field can't be printed the way you want,
> is because we don't have a command line name of letter to apply the
> option, usually because we didn't get around to doing it, or nobody asked
> for it.
> 
> OK, understand that the default status fields are simply a convenient way of
> presenting the TCP state progression in a simple fashion. We have more
> information in the Argus records, as we track the perceived TCP states per
> side of the connection, but how would you like to print them?
> 
> In raxml(), which is now obsolete (replaced with the '-M xml' option), we
> printed out the entire contents of the ARGUS_TCP_DSR.  That was argus-2.x.
> In argus-3.0, we have more and less TCP information available, depending
> on how you setup your argus().  So if you want some new TCP printing support,
> we should discuss what the information is, what it means, and how to print it.
> 
> Currently, the combined TCP status field (default TCP output with the -z option),
> tracks the progression of the TCP state machine, and the direction of the TCP control
> packets that establish the various TCP states is indicated by the assignment of Src
> and Dst for the flow.   Who sent the SYN ('s') ?  The Source.  Who sent the
> SYN_ACK ('S')?  The Destination.  In fact that is how the Source and Destination
> are determined, and in some cases of TCP mediated scans, the direction seems
> confused, because the scanner is violating the TCP state machine to get the
> targets to respond.   Notice that the use of lower case and upper case tracks the
> source and destination.
> 
> The states for TCP are derived from the indications that Argus stores in the TCP
> DSR.  We capture "SAW_SYN", "SAW_SYN_ACK", "ESTABLISHED", "SAW_FIN",
> "SAW_FIN_ACK", "SAW_RESET" on each side of the connection, as well
> as the state that argus() thinks the TCP connection is in.  And with each status
> report, we zero most of these bits, so we can know what control packets were sent,
> when.
> 
> So, with all of that, we can print out all that you ask, just need to know what syntax
> to use to print the fields.
> 
> The flags format, because its simply the OR'ing of the TCP flags during
> the status interval, you lose massive amounts of information, like direction
> etc.....   However, when you print the status field using the "-Z" option, you have
> the flags for the source, the an '_' and then the flags for the destination.
> 
> Maybe you haven't seen this because your default status field width isn't large
> enough to print the whole indicator?
> 
> "man" records are argus management records.  They convey status of the argus
> data source, which can be argus() or radium(), and act as keep alives for the
> argus transport stream.   I believe that they are described in the man pages.
> 
> Carter
> 
> On Nov 21, 2009, at 10:53 PM, Matt Brewer wrote:
> 
>> Hello,
>> 
>> I have a few questions and ideas I'd like to share.
>> 
>> Some of the flows in my captures are marked EC (This is with the -z option to show mimic tcp states) and I haven't been able to determine what the C stands for, any idea what it means?
>> 
>> Also, I've been working with the states field a lot with the -z option, and its come to my attention that the sSEfFR orientation of the flags doesn't actually give me indication of who sent what packets with what tcp flags.  I'm aware I can remove the -z and use the -Zs or -Zd option and it will give me an output of with tcp flags were set for each direction, but it would be nice to actually have both options displayed.  If I use the -Zb option, it looks like it attempts to print out both states deliminated by an underscore, however the field appears to be truncated to 5 characters and is often cut off. And even if it wasn't cut off, the tcp flags aren't displayed it order of occurrence.
>> 
>> Is there any reason the state field cannot keep the occurrence of flags in order? It would be incredibly useful to display the state of the flow in order. Ideally I would like to see the tcp flags as lower case letters as the source produced flags, and upper case letters as destination produced flags.  A system like this would allow us to easily determine which side of the flow tore down the TCP session, either via a FIN or RST.
>> 
>> Also, I've recently seen the "man" protocol in my captures.  What exactly is this supposed to indicate? Some of the "man" flows are marked with STP or STA in the state field.  I am assuming that "man" refers to switch management protocols? Correct me if I'm wrong.
>> 
>> Also, the "man" protocol flows with the state "STA" have zero destination or source packets. Which is very bizarre, I do not understand how a flow could exist without packets.
>> 
>> Oh also, what is the "offset" field for? The man pages are rather vague "record byte offset in file or stream."
>> 
>> Thanks in advance, argus is a wonderful tool.
>> 
>> ===========================
>> | Matt Brewer
>> | CCNA
>> | www.sheridantutorials.com
>> ===========================
>> 
> 
> 
> 
> 
> 
> 
> 

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20091210/1b84b039/attachment.bin>