Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Patch, RFC] to TCP Sequence Analysis

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 23 Mar 2012 20:39:43 -0700
On Mar 23, 2012, at 6:11 PM, Martin Mathieson wrote:

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

Presumably because it can hold multiple IP datagrams.

There are probably many parts of Wireshark that assume that a packet at the lowest visible layer will not contain more than one packet from a higher layer, so that the frame number can be used to uniquely identify packets at all layers.

I suspect LTE is not the only link layer that violates this assumption.

(In addition, assuming that a packet at the transport layer will not contain more than one packet from a higher layer is also not valid; TCP violates that assumption.)

So, in the general case, we'd need more than just the frame number; a pairing of {frame number} and {offset, relative to the beginning of the frame, of the first byte of the next layer of packet} might suffice, although it doubles the space required for the key.

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

That's another possibility, although it's specific to LTE.

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

"Index" meaning "if a given LTE MAC layer frame has more than one higher-layer packet in it, use the ordinal number of the packet"?