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.
[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. On Mon, Jul 2, 2018 at 4:05 PM, Roland Knall <[email protected]> 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 <[email protected] > >: > >> 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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
