Re: Dealing with aggregated packets

[Mike Morrin <morrinmike () gmail com>]

I also played with this concept a few years ago when working with a 
proprietary aggregation protocol.  I am not sure if I still have my 
prototype code.  I seem to remember that features such as filtering were 
easily broken and difficult to fix.

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

Mike

On 02/07/2018 21:18, Darien Spencer wrote:
> Hey devs
> There's something that has been bothering me in my 
> wireshark experience and I wanted to bring to discussion
> *Some protocols can aggregate several payloads *such as *SCTP and TCP*
> Viewing those in wireshark could be difficult if many payloads are 
> present.
> Specificly *the Info column gets long quickly *(assuming fences are used)
> Here is an example - the info column of a SCTP packet with 6 payloads:
> https://i.imgur.com/GeA2WmU.png
> It can be challenging to spot a specific packets in those 
> overpopulated info columns
> further more, once you find the right packet by the info column you 
> are served with your next challenge -
> finding which of the aggregated packets in the protocol tree is the 
> one you are looking for.
> I was thinking about introducing a newer concept to wireshark in the 
> form of *"sub-packets"*
> Maybe that's a cosmetic feature to add to the Qt GUI and maybe it 
> required some changes to the dissection engine. I'm not familiar 
> enought with the GUI to tell.
> What I had in mind is an option to 'expend' a packet in the main view 
> so its aggregated sub packets are seen in a tree under it
> Here's a mock hoping it's get the idea across:
> https://i.imgur.com/WfSvg6x.png
> I can imagine how this might require a change to the way info is saved 
> in the dissectors.
> Does anyone else feel this is an issue when analysing traffic?
> Is this a feature fitting the GUI/User experience guidelines of wireshark?
> Cheers,
> Darien
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>               mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



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

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