["Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>]

Hi list Hi Joerg
Attached small patch is initial support in ethereal to do SEQ/ACK analysis
for TCP sessions.
I have tested it and it seems to work fine but would like external testing
before checking it in
since bugs in the TCP dissector would be bad.

The patch adds a new option to TCP to allow it to do simple analysis of TCP
sessions.
Currently it will keep track of all un-ACKed segments in the TCP sessions
and everytime it sees a
new segment or ACK it will check for and flag some conditions some of which
are
* if an ACK moves the left edge of the window two new fields will be
displayed
   1, the frame ID of the segment this ACKs
   2, the RTT time between the ACKed segment and the ACK.
* if an ACK is right of the right edge, this is flagged as a potential lost
packet.
   The ACK ACKs a packet we have not seen and thus(maybe) is lost.
* if a new segment arrives which is left of the right edge, this is flagged
as a retransmission
* if a new segment arrives which is right of the right edge, this is flagged
as a lost packet
   since the previous one which should have moved the right edge was not
seen.
If there is any data to report as above, a new subtree is created in the TCP
tree to hold these
entries. This not all TCP segments have this subtree, only those that have
any information
to display. This is probably ~50% of the TCP packets.
If one of the three errors occured (2xlost packet, 1xretransmission) this
will also be flagged as
a "[TCP ...]"  error indication prepended to the COL_INFO text.

The patch can not yet detect and flag TCP-keep-alives. This will be fixed.

The patch does not yet provide an option for relative sequence numbers, an
option that will also be added.

The patch does NOT handle sequence number wrapping. This may take more
effort to fix since it requires
>32bit arithmetics or simulation thereof. Can be solved by just adding an
extra int variable keeping track of
wraps but would uglify the code. Sequence numer wrapping does not occur THAT
frequently anyway unless you
use multigigabyte sized capturefiles a lot. Not even myself use capturefiles
that big since other problems are more
disturbing at those sizes, such as state buildup and execution speed.


The option provided by the patch will when enabled, as always, eat quite a
lot of memory but in the tests I did on
100k+ packet capturefiles it was still quite ok.

Joerg and others interested, please test it and report any malfunctions it
introduces in teh quite vital TCP dissector before it gets checked in. The
RTT field is quite useful imho.




----- Original Message -----
From: "Joerg Mayer"
Sent: Tuesday, July 23, 2002 9:19 PM
Subject: Re: [Ethereal-dev] TCP reassembly retransmission/overlap flags


> On Tue, Jul 23, 2002 at 06:38:48PM +1000, Ronnie Sahlberg wrote:
> > I have given it some thoughts and unless Joerg wants to do this himself
I
> > can set aside the other projects-ideas for a while and rewrite my first
test
> > implementation i
> > posted earlier to be a proper implementation.
>
> I won't find the time to work on that before the weekend, and even then
> there is no guarantee that I will manage to get this done (I'm a lousy
> programmer!).
>
>  ciao
>     Jörg
>

Attachment: tcp.diff
Description: Binary data