> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
> Sent: 18 July 2009 00:01
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] How to reassemble split TCP Packets -
> togrouptogether with full messages? - Email found in subject - Email
found
> in subject
>
>
> On Jul 17, 2009, at 2:14 PM, Tamas Somogyi wrote:
>
> > I can see two solutions:
> > 1. Extend the design of tcp_dissect_pdus() to call dissectors for
> > the packet as described below.
>
> What's described below?
As I wrote in my original mail:
"In my view, the main problem is that get_foo_message_len() gets called
second times (in step A3) by tvb->length=Size(m4) instead of
Size(m4)+Size(m5)+Size(m6a)"
>
> > 2. Possibility to modify the existing content of a column. I'm
> > thinking about adding a function to column-utils.c, let's call
> > col_modif_str(cinfo,el,str), which -instead of appending- overwrites
> > the info up to the length of the existing string, if there's a
> > fence. If no fence yet, it just sets the string by calling
> > col_set_str(). It needs some more ivestigation on my side as I'm not
> > familiar with such internal code , but it seems the easier way.
>
> Or *some* change to the way columns are processed.
>
> Note that if you have, encapsulated in TCP, protocol A, and if you
> have, encapsulated in protocol A, protocol B, getting the Info column
> to give information about all packets in a link-layer frame, at the
> top level, is harder, as that information is put there by the
> dissector for protocol B - but you don't end up with protocol B's
> dissector called sequentially for each packet. Instead, you'd have
> protocol A's dissector called for the first packet, then protocol B's
> dissector, then protocol A's dissector for the second packet, then
> protocol B's dissector for the second packet.
>
> Perhaps what we really want is a *stack* of Info columns, so that the
> protocol A dissector can just keep appending to the Info column at its
> level of the stack; that Info column would start out empty (as the
> Info column for the protocol below it in the stack would be separate).
>
> Once they're all filled in, the topmost Info column could be what's
> displayed - or we could, perhaps, have the packet list be a tree view,
> so that you could open up a row in the tree view and see the Info
> column (and Protocol column, and perhaps other columns) for *all*
> layers of the protocol.
>
> That opens up the possibility of another layer of tree view, so that
> you could have an Info column with information for all the packets
> within a link-layer frame, and then open that up and see the Info
> columns for each of those packets individually.
>
> However, the UI stuff isn't required in order to implement the stack
> of columns - we could leave the UI the same, and just implement the
> stack and have the topmost element of the stack generate the columns.
> The UI stuff could be designed and done later.
I'm not sure that I fully understand the above concept of info "stack".
I think Info column is useful if the user can see the description
immediately (i.e. without browsing a stack) on the topmost protocol
while scrolling the packet list in the main window. If needed, details
can be seen by selecting the frame and diving into the Packet Details
and Bytes panes.