Wireshark-dev: Re: [Wireshark-dev] Dealing with aggregated packets

From: Mike Morrin <morrinmike@xxxxxxxxx>
Date: Wed, 4 Jul 2018 08:40:42 +0200


On 03/07/2018 07:39, Guy Harris wrote:
On Jul 2, 2018, at 10:34 PM, Mike Morrin <morrinmike@xxxxxxxxx> wrote:

One idea I had was to NOT give the aggregated packets real packet numbers (in the traditional sense), but give them sub-packet numbers which are displayed as x.y where x is the aggregation packet where the aggregated packet finishes and y is the aggregated sub-packet number.  Note that his scheme should be extensible for sub-packets within sub-packets (x.y.z etc).
Is there any need to give them packet numbers at all?  The top-level tree items can have frame numbers, but the tree items underneath that need not have one.
The project where I needed this had a logging protocol where some low-level parameters of a real-time process were being monitored, producing a large number of nearly identical small packets, which to save bandwidth were aggregated and transferred every few milliseconds.  The problem I was solving was to be able to filter to find packets with out-of-spec parameters.  That can be accomplished without numbering the aggregated packets, but if I then want to switch to an unfiltered view and see a number of packets either side of the interesting one, I need a handle (packet number?) to be able to find it amongst the dozens of other aggregated packets.   It is also awkward when sharing data to say look at the 47th aggregated packet in frame 2375.

When I was working on this I could also see that the idea should be extensible for other scenarios, such as tunneling protocols using aggregation which might be carrying packets of other aggregated protocols (there are examples of this in 3gpp protocols).

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus