TCP flags

[Carter Bullard]

Hey CS,
The data is 'correct', its just you have chosen an interesting example.

You are looking at the last two packets of a TCP connection that the
probe has been tracking for a while.  The probe is aware of the history
of the TCP state for the life of the connection, and reports that
with every record.  This is important, for a large number of reasons,
but the most important reason is to assist readers in realizing which  
port
is the service port (the port requested at TCP connection establishment
time), and which is the random ssap.   Also its important in  
discriminating
a FINACK scan from the delayed FINACK volley of a real TCP connection.

The "-z" option prints out the connection state history, so in your case
you are seeing that the connection went through 's', 'S', 'E', and  
'f', so
at one point in the life of the TCP connection, the probe saw the syn, a
syn|ack, an ack (established) and then a fin from the initiator, but  
no 'F',
from the other side.

In support of these states, we have special state filter keywords, like
'init', 'synack', 'est', 'con', 'data', 'finack', 'wait', 'normal',  
'clo'.

The flags, on the other hand, are the bits that were seen in the packet
header.  These are there for TCP state verification, etc..., and the
scope of these is only within the period of the status record.  For this
case, the "-Zb" option shows you that the two packets had the FIN,
the ACK bits set in  one packet, and the ACK bit set in the return  
packet.

In support of these flags, we have special flags filter keywords, like
'syn', 'ack', 'rst', 'push', 'urg', 'ece', 'cwr' and 'fin'.

Try this as a comparison:

    ra -b - synack

and compare it to

    ra -b - syn and ack

I think the last one is really what you intended to use?  Now that
I am looking at it, we probably need to come up with better keywords
so that the 'synack' isn't confusing?


Carter





On Nov 27, 2006, at 11:23 AM, CS Lee wrote:

> Russell,
>
> Thanks, I'm looking at the output and thinking the right one should  
> be -Z as there are only 2 packets in the flow. But how about  
> primitives specific supported TCP flows, I'm trying to use it to  
> filter all the necessary flow that I need and using synack returns  
> fin+ack and fin flow don't seem to be right.
>
> I think tcp flags state is very important when comes to debugging  
> certain traffics thus it should be done correctly especially in  
> upcoming 3.x.
>
> Thanks.
>
> On 11/27/06, Russell Fulton <r.fulton at auckland.ac.nz> wrote:
> You can blame me for the tcp flags, I added them to 1.8.X...
>
> I used the z flag because it was just about the only letter left.
>
> I have now forgotten exactly what -z does.  Hmmm... it comes back
> slowly  Argus 1.x recorded TCP states that the connection went through
> and this is what -z displays.  With version 2.0 Carter added the  
> ability
> to record all the flags that have been seen in each direction and this
> is what you get with uppercase Z.
>
> Now I've not been paying too much attention to the
>
> Russell.
>
> CS Lee wrote:
> > Carter,
> >
> > I'm comparing the result of -z and -Z b when reading argus flow.
> >
> > ra -Z b -r test.argus -nn - synack
> > 17:48:45.553602               6       1.2.3.4.1553      ->
> > 2.3.4.5.80            1        1
> >           60           60  FA_A
>
> This flow consists of *one* packet in each direction one with a FIN  
> and
> one in the other direction with a FIN+ACK.
> >
> > ra -z -r test.argus -nn - synack
> > 17:48:45.553602               6       1.2.3.4.1553      ->
> > 2.3.4.5.80            1        1
> >           60           60  sSEf
>
> Hmmm.... I don't see how this can be right ( or, more likely, I may  
> have
> forgotten the exact semantics of the tcpstate stuff in argus).  As the
> flow data show there is only the one packet in each direction  
> ( i.e. what
> we have here is the fail end of a flow not the complete article) so I
> don't see how it should be recording the syn and syn+ack.
>
> It was because of issues like this that I asked Carter to implement a
> new attribute that just recorded the actual flags seen.
> >
> > Is it shown correctly as there should be SA from dst IP, I'm  
> confused
> > with these two results or the -Z b seems to show flags when it last
> > seen in the flow.
>
>
>
> -- 
> Best Regards,
>
> CS Lee<geekooL[at]gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20061127/bbeafad4/attachment.html>