Wireshark-dev: Re: [Wireshark-dev] Dealing with aggregated packets
From: Mike Morrin <[email protected]>
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 <[email protected]> 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.