Wireshark mailing list archives
Re: Dealing with aggregated packets
From: Roland Knall <rknall () gmail com>
Date: Tue, 3 Jul 2018 09:44:53 +0200
This discussion was also voiced by Evan Huus back in 2015. For some reason, I cannot find the original email, but here is the gist of it:
I've been thinking about this and trying to come up with a way to
gracefully (and backwards-compatibly) add this
information to our existing data-structures, and I'm currently thinking
of just adding it as a flag to the field_info
struct (i.e. defining something like FI_STARTS_NEW_RECORD). As far as
I've been able to determine, these
flag values are accessible everywhere we need them to be (specifically:
in the UI and in the display-filter engine),
and it makes creating new records backwards-compatible and cheap (just
some new macro to set the flag).
My only concern right now is how difficult it will actually be to check
this value in the display filter logic - I don't know
nearly enough about the dfvm to know if checking for fields in the same
"record" is easy or not with the info stored this way. Some part of this discussion can be found at: https://www.wireshark.org/lists//wireshark-dev/201508/msg00090.html It has been discussed over the years, and always boils down to the following issues: - Packet Dissector addition to determine, where the sub-packets / records start - display filter logic on how to filter correctly - visual representation For performance sake, we could leave the display filters as they are, and handle the splitting part purely in the visual representation. Display filters would not to be changed at all, except if a user specifically wants to filter for the n-th sub-packet. But the question would be, how to determine in the visual representation, which packets to be displayed and which would not be displayed, and on that part we would need a matching field index and some kind of correlation of matching that field to a sub-record. So for instance, if I know, the display filter matched because of the n-th occurence of a field, and that field belongs to sub-record y, I can hide all other sub-records. On caveat though whould be display filters, which match BECAUSE there are multiple fields in a packet which belong to different sub-records. That would be an issue. For visual representation I would go with sub-numbers for each record for display only. It makes it somewhat easier to read in my book, but that is not a necessity. cheers Roland Am Di., 3. Juli 2018 um 08:42 Uhr schrieb Jakub Zawadzki < darkjames-ws () darkjames pl>:
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 () gmail com> 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 () mail com: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
___________________________________________________________________________ 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:
- Dealing with aggregated packets Darien Spencer (Jul 02)
- 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)