Wireshark-dev: Re: [Wireshark-dev] Dealing with aggregated packets

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Tue, 3 Jul 2018 09:11:50 -0400


On Tue, Jul 3, 2018 at 2:42 AM, Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> 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/lists/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.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?

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...