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
