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

From: Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx>
Date: Tue, 03 Jul 2018 08:42:23 +0200
Hello,

W dniu 2018-07-02 22:33, Jeff Morriss napisał(a):
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.

It seems I did one in 2012, https://www.wireshark.org/lists/wireshark-dev/201208/msg00200.html

patchset: https://www.wireshark.org/~darkjames/multicols/
screenshot: https://www.wireshark.org/~darkjames/protocolstack.png

looking in 0004 patch, the idea was that every protocol, (or PDU) would
call pinfo->cinfo = add_new_column_set(pinfo, TRUE);

which would create new (sub)row in column list.

[1] https://www.wireshark.org/lists/wireshark-dev/200606/msg00147.html

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

I am no longer reviewing changes actively, but as far as I know we don't have filtering for columns? Do we?

Jakub.

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:
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