Ethereal-dev: Re: [Ethereal-dev] first packet in capture is dissected three times
On Thu, Jun 20, 2002 at 12:58:29PM -0400, Joe Litman wrote:
> I have a small capture file that contains 10 RTP packets. I noticed that
> when I load the file (ethereal 0.9.1 on W2K server), the first packet is
> passed to dissect_rtp three times. The first time the packet is passed to
> dissect_rtp, tree is NULL. The second and third times, tree has a valid
> value. All other packets in the capture are passed to dissect_rtp only once
> and tree is NULL.
>
> This does not effect the display of the file but I was wondering if this
> behavior is intentional and if so why.
The fact that it gets called multiple times appears to be a consequence
of the way GTK+ works. When Ethereal reads the capture file, it
dissects every single frame, in sequential order, as
1) it needs to do so in order to get the values to put in the
columns for that field in its row in the packet list pane
(first pane);
2) it needs to allow the dissector to build any internal state
it'd need to
dissect that frame later if you click on it;
dissect subsequent frames whose complete and correct
interpretation would depend on the contents of previous
frames (e.g., a request/response protocol where the
response cannot be interpreted without knowing what the
request was - ONC RPC-based and DCE RPC-based protocols
require this, for example).
However, it does not need to build the full protocol tree for packets on
that pass, so it passes a NULL tree value. That prevents the
dissectors from building the protocol tree, which means they spend less
CPU time dissecting.
However, when the first item is added to a GtkClist (the widget used to
implement the packet list pane, GTK+ appears to select that item and
deliver a "this item was selected" for that item. Ethereal responds to
that item by dissecting the frame, constructing its protocol tree, and
displaying that protocol tree in the protocol tree pane (second pane).
That accounts for the second call to the dissector.
I'd have to look at the code to see why there's a third call, but I
think Ethereal might also explicitly select the first frame (it might
not be assuming that GTK+ will do so), provoking another dissection and
display.
Note that no dissector can *ever* assume it will be called only once,
nor can it ever assume that it will only be called on the Nth frame
immediately after it's been called on frames 1 through N-1.
