> > - continue what I have done so far, and use regular dissect routines
> > (requires some data to be preserved between dissect invocation). I made
> > assumption that dissect routines are invoked in order of packet arrival
> > (no sure).
>
> Yes, they're processed in order. During the initial pass,
> 'tree' is set to NULL, so the proto dissection routines only parse enough info
> to put into the list of packets. When a packet is selected via the GUI, or
> when a display filter is being processed, the proto dissection routine is
> called again, but this time with 'tree' pointing to something, telling
> the dissector that it needs the decode information.
Note that the first line of the above could, by itself, be treated as a
useful statement here:
> Yes, they're processed in order. During the initial pass,
by repunctuating it as
Yes, they're processed in order, during the initial pass.
This is a useful statement because that's the *only* time they're
guaranteed to be processed in order; when the dissection routine is
called later when a packet is selected via the GUI, there's no guarantee
that they'll be called in order.
Thus, any information that can be derived only by an in-order processing
of packets needs to be saved during the initial pass, so that it can
later be retrieved on subsequent calls to the dissector.
We currently have no mechanism for attaching information such as that to
a packet for use when subsequently dissecting a frame; Richard Sharpe
has been thinking about a mechanism for doing that.
> > - once the last chunk of the DCII packet is detected, I can try to trace
> > back all the pieces and add a virtual packet to the panel (need some
> > neat gui linking among all packets involved).
>
> Yep. #3 is the way to go. It needs to be optional.. One view shows all
> fragmented packets normally, another view shows packets unfragmented
> as much as possible.
Note that it might also be useful to, when dissecting a frame that's
part of a higher-level packet, show, in the part of the protocol tree
for the higher-level protocol in question, the fields that are, in whole
or in part, contained within that frame, so that you see a partial
protocol tree.
When seeing an "unfragmented as much as possible" view, you might have a
different packet list that, instead of having one line per frame, has
one line per higher-level packet, although, in that case, the question
is "*which* level?", if, as I infer might be the case for his protocols,
you have protocol X whose packets are made out of multiple frames, and
protocol Y whose packets are made out of multiple protocol-X packets.