Wireshark mailing list archives
Re: Dealing with aggregated packets
From: Jeff Morriss <jeff.morriss.ws () gmail com>
Date: Tue, 3 Jul 2018 09:11:50 -0400
On Tue, Jul 3, 2018 at 2:42 AM, Jakub Zawadzki <darkjames-ws () darkjames pl> wrote:
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/list s/wireshark-dev/201208/msg00200.html patchset: https://www.wireshark.org/~darkjames/multicols/ screenshot: https://www.wireshark.org/~darkjames/protocolstack.png
That's what I was thinking of, thanks!
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.
I was thinking along the same lines; the upper-layer dissectors (for TCP this could be done in tcp_dissect_pdus()) just need to say where the PDUs start (and end?). Store that info and let the UI sort out the presentation.
[1] https://www.wireshark.org/lists/wireshark-dev/200606/msg00147.htmlI 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?
Not to my knowledge. But I was thinking of filtering on the PDUs. One of the aggravating things with multiple PDUs in a single frame is trying to find PDUs (not frames) where protocol.field1 = X and protocol.field2 = Y. Today I'd write that as "protocol.field1 = X && protocol.field2 = Y" but that will return frames where, for example, PDU1 has protocol.field1 = X and PDU2 (in the same frame) has protocol.field2 = Y. I admit that's a-whole-nother level of complexity...
___________________________________________________________________________ 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)