On Sat, Mar 24, 2012 at 3:39 AM, Guy Harris
<guy@xxxxxxxxxxxx> wrote:
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.
Yes, often one RLC PDU will hold more than one PDCP PDU, which for user-plane traffic contains an IP frame.
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.
For LTE, I do similar sequence analysis at the RLC and PDCP layers. The first implementations used only the frame number, which resulted in the same problem. I added to those key things specific to those protocols, i.e. channel-type / channel-number / sequence number to avoid attaching the analysis to the wrong PDU within the frame.
(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.
In this case, my choosing that key was specific to TCP. And I liked the idea that instead of allocating a new entry for every single segment, repeated ACKs sent within the same frame could share that entry, as their analysis would (I think) be the same. Also, I don't like the idea of the TCP dissector needing to know which segment it is within the frame. Or needing to know where its tvb happens within the overall frame. It may be reassembled (as RLC does for PDCP), decompressed or deciphered into a separate tvb with a small offset that may clash with other child tvbs.
> 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"?
Yes, although actually you could have multiple RLC PDUs within the same MAC PDU, or multiple segments within the same RLC PDU (which can be logged without MAC), so its not clear how/where this would be done.
I think I have talked myself into believing that my patch is the right thing to do. i.e. that its best to add to the key whatever makes sense for that protocol. That is neater than having the protocol need to look for where it occurs within the frame, or for every possible lower-layer protocol that could hold it needing to tag it with an index. And the worries about child tvbs above.
In fact, a bolder man than me might even be tempted to remove the frame number from the key for TCP. It would make the key shorter (8 bytes rather than 12), and would lead to more sharing of the analysis result entries in the table. But I'd be worried about the (very remote) possibility of the sequence number wrapping and the wrong segment getting tagged with very old analysis.
I can still rework this if anyone feels strongly about it, otherwise I'll submit it in a couple days.
Martin
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
