Wireshark-dev: Re: [Wireshark-dev] Dealing with aggregated packets
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Mon, 2 Jul 2018 16:33:44 -0400

Yes please.

It's an idea that's been tossed around since at least 2006[1].  Someone (Jakub?) had played around with it but eventually gave up; unfortunately I can't find the reference to that.


I think the UI presentation is one thing but the next (and equally important IMO) thing is how the filtering will work.

On Mon, Jul 2, 2018 at 4:05 PM, Roland Knall <rknall@xxxxxxxxx> wrote:
This is a feature, that has been discussed on/off for a longer time now. I think, this mockup is by far the best I've seen so far. You have my vote for implementing it, and I think it will be a big improvement.

cheers
Roland

Am Mo., 2. Juli 2018 um 21:19 Uhr schrieb Darien Spencer <cusneud@xxxxxxxx>:
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:
 
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:
 
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