Wireshark mailing list archives
Re: Dealing with aggregated packets
From: Ivan Nardi <nardi.ivan () gmail com>
Date: Tue, 3 Jul 2018 16:35:30 +0200
Hi I work with sctp pcaps very often and I have always found that Wireshark doesn't handle them in a practical way The far biggest issue is the display filter logic As a workaround, I have to externally pre-process the traces and "de-chunk" the sctp packets: when every sctp packet contains only one chunk everything works like a charm, as usual
From a user point of view, I would like an improvement in the display
filters: * you should be able to match a specific sub-packet. I mean, when the filter is something like "sccp.xxx == AAAA && gsm_a.yyyy == BBBB" I do expect the matched fields to be on the same sub-packet, not on different chunks of the same sctp packet. AFAIK one way to achieve this goal is forcing all protocol fields above sctp (or any other "aggregating" protocol) to be per sub-packets, not per packets (as today). In this way, there shouldn't be multiple fields anymore * when there is a display filter (involving sub-protocol fields), only matching sub-packets should be visualized in the packet list * you should be able to export only visualized sub-packets in a valid file. Just my 2 cents, based on my personal workflow I fully understand that my wish-list requires a huge amount of work; improving only the visual representation of the packets/sub-packet should be an important step forward anyway I don't have the expertize to write GUI or "core" code, but I am more than willing to test any solutions Thank you very much for bringing up this topic Ivan On Mon, 2 Jul 2018 21:19 Darien Spencer, <cusneud () mail com> 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 () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Dealing with aggregated packets, (continued)
- Re: Dealing with aggregated packets Roland Knall (Jul 02)
- Re: Dealing with aggregated packets Jeff Morriss (Jul 02)
- Re: Dealing with aggregated packets Jakub Zawadzki (Jul 02)
- Re: Dealing with aggregated packets Roland Knall (Jul 03)
- Re: Dealing with aggregated packets Jeff Morriss (Jul 03)
- Re: Dealing with aggregated packets Jeff Morriss (Jul 02)
- Re: Dealing with aggregated packets Roland Knall (Jul 02)
- Re: Dealing with aggregated packets Guy Harris (Jul 02)
- Re: Dealing with aggregated packets Darien Spencer (Jul 02)
- Re: Dealing with aggregated packets Mike Morrin (Jul 02)
- Re: Dealing with aggregated packets Guy Harris (Jul 02)
- Re: Dealing with aggregated packets Mike Morrin (Jul 03)
- Re: Dealing with aggregated packets Guy Harris (Jul 02)
- Re: Dealing with aggregated packets Ivan Nardi (Jul 03)