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

[Mike Morrin <morrinmike@xxxxxxxxx>]

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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

Virus-free. www.avast.com