Wireshark mailing list archives

[Patch, RFC] to TCP Sequence Analysis


From: Martin Mathieson <martin.r.mathieson () googlemail com>
Date: Sat, 24 Mar 2012 01:11:53 +0000

Hi,

I'm now needing to analyse TCP conversations carried over LTE
MAC/RLC/PDCP/IP.  So one frame in a log or capture can hold many segments
of the same TCP conversation.

The current implementation for TCP analysis is that there is a tcp_analysis
struct for each conversation.
Within that struct there is a map (emem_tree_t) from frame number ->
tcp_acked

The tcp_acked struct holds the result of the analysis done on a segment
during the first pass through the segments of the TCP conversation.

When a frame is re-dissected, we look up the appropriate tcp_acked struct
for the segment and apply its findings to the segment currently being
dissected.  The problem for me is that I often have several segments with
the same frame number, so they all get tagged with the same (last?)
analysis stored in a single tcp_acked struct.

My change was to expand the key now to include
frame+sequence-number+ack-number (where the sequence-number and ack-number
are the raw, rather than relative, values), which works well for me.


Is there a more appropriate key for looking up the segment?  I did think
about adding an index for the segment within the frame, but that would be
messy, and if you had to segments with the same seq+ack, I think the same
analysis would always apply.

I know that the TCP analysis functionality gets used a lot, so I'm very
wary of breaking it.  At the very least this will slow it down a little and
use more memory.  But I surely can't be the only person who has this
problem...

Thanks,
Martin

Attachment: packet-tcp.c.diff
Description:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: