Question about states

[Peter Van Epp]

On Sat, Nov 21, 2009 at 10:53:50PM -0500, 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?
> 

	First, a man page bug because it isn't in the ra man page :-). From
a quick read of the code it looks to be indicating a normal close:

common/argus_util.c line 14986:

 ... status & ARGUS_NORMAL_CLOSE ... appends a "C" to the buffer. 


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

	I'll leave this one to Carter, but if I remember correctly from 
previous discussion there is (or was as it is several versions ago) a space 
issue in one of the dsrs and some less important flags were dropped.

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

	man records are about the state of the argus server not directly about
input flows. Here is a quick cheat sheet (from 3.0 and 2.0.6 but I don't 
imagine it has changed much if any since then) that I did the second or third
time I neeeded to dig this out of the code :-). To check edit 
common/argus_util.c, search for the routine (such as ArgusPrintStartDate)
and see what it will do in the ARGUS_MAR case, as thats what will be in the
printed field. Note some of the routine names below may have changed just to
keep things interesting :-):

argus  mar format  3.0

stime	ArgusPrintStartDate	argus_mar.now.tv_sec
ltime 	ArgusPrintLastDate	src.start.tv_sec
    	ArgusGetIndicatorString blanks
flgs	ArgusPrintFlags		blanks
proto	ArgusPrintProto		"man"
saddr	ArgusPrintSrcAddr	argus_mar.queue
sport 	ArgusPrintSrcPort	argus_mar.dropped
dir 	ArgusPrintDir		blanks  (now version number)
daddr	ArgusPrintDstAddr	argus_mar.bufs
dport	ArgusPrintDstPort	argus_mar.clients
spkts 	ArgusPrintSrcPackets	argus_mar.pktsRcvd
dpkts 	ArgusPrintDstPackets	argus_mar.records
sbytes 	ArgusPrintSrcBytes	argus_mar.bytesRcvd
dbytes 	ArgusPrintDstBytes	argus_mar.bytes
state	ArgusPrintState		state  (current?)

2.0.6 

starttime	ArgusPrintStartDate	argus_mar.startime
lasttime	ArgusPrintLastDate	argus_mar.now
trans 		ArgusPrintTransactions	blanks
dur		ArgusPrintDuration	argus_mar.startime
avgdur		ArgusPrintAvgDuration	argus_mar.startime
snet		ArgusPrintSrcAddr	argus_mar.argusid
addr		ArgusPrintSrcAddr	argus_mar.argusid
dnet		ArgusPrintDstAddr	argus_mar.nextMrSequenceNum
daddr		ArgusPrintDstAddr       argus_mar.nextMrSequenceNum
proto		ArgusPrintProto		" man "
sport 		ArgusPrintSrcPort	argus_mar.major_version,
dport		ArgusPrintDstPort	argus_mar.flows
stos		ArgusPrintSrcTOS	argus_far.attr_ip.stos (not MAR specific)
dtos		ArgusPrintDstTOS	argus_far.attr_ip.dtos (not MAR specific)
sttl		ArgusPrintSrcTTL	argus_far.attr_ip.sttl
dttl		ArgusPrintDstTTL	argus_far.attr_ip.dttl
sbytes		ArgusPrintSrcBytes	argus_mar.bytesRcvd
dbytes		ArgusPrintDstBytes	argus_far.dst.bytes (not MAR specific?)
spkts 		ArgusPrintSrcPackets	argus_mar.pktsRcvd
dpkts		ArgusPrintDstPackets	argus_mar.pktsDrop
sload		ArgusPrintSrcLoad	Not MAR specific
dload		ArgusPrintDstLoad`	Not MAR specific
loss		ArgusPrintLoss		blanks?

	Usually of most interest in the above is the sport field which is the
dropped packet counter (although not the only potential source of lost packets)
from libpcap, i.e. libpcap overwrote a packet because the buffer had filled 
before argus read it. The start time field is when the first flow was seen 
and end time is the time now (which for a long running argus can be very far
appart :-)). 


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

	That it is!


> ===========================
> | Matt Brewer
> | CCNA
> | www.sheridantutorials.com
> ===========================

Peter Van Epp