Hi Evan
Thanks for the reply.
More-or-less. Each packet is dissected once (with, I believe, NULL
tree and NULL cinfo) as it is loaded or captured. All other
dissections are triggered as callbacks from the GUI based on which
packets are visible. Selecting a packet will trigger a dissection with
a non-NULL tree (in order to display the complete dissection tree).
Scrolling the summary list will (should?) trigger dissections with
non-NULL cinfo in order to display the column info, unless that's
being cached somewhere.
I tried scrolling the summary list but this does not appear to
cause the dissector to be rerun. Clicking on an individual packet does
but its cinfo is always NULL.
It probably also depends on whether this is the GTK or QT-based
interface you're using, since they may behave slightly differently in
this regard.
I am running the standard Windows build, which I think is GTK.
There are certainly cases (like single-pass tshark) where COL_INFO is
limited to "present and past" data and no future data, so it has to be
coherent in that case. However, it *should* always display future data
when loading captures from a file into the GUI.
I just tried a quick test. It appears that on a live capture, OK
quite a small one, scrolling the summary pane never re-dissects with a
valid cinfo. If I save the capture and reload it from file then it does
re-dissect with a valid cinfo as you scroll.
To be consistent between these various mode perhaps I should
restrict my COL_INFO text to what I can determine from the present and
past packet data only and not rely on the GUI requesting the dissector
to rerun with a valid cinfo.
I can sort of guess at the destination channel ID for my protocol
from the destination UDP port number. I was trying to avoid this as the
base port number can vary under user control, but as long as they don't
pick a stupid valid I should be OK.
In the latest development releases, the expert information API has
been changed to be filterable just like regular packet fields, so that
should be sufficient. If there is a case where the COL_INFO is not
refreshing when it should we can also try to fix that, thought it will
likely be tricky.
I was also using the COL_INFO for protocol violations. Maybe the
better approach is to use the protocol tree pane to list these, flagging
them with appropriate expert info tags. As you say you can then use that
to filter.
I did have a look through the TCP dissector as I thought that was
flagging protocol violations in the COL_INFO column, but I now think its
only packet data shown there and the protocol violation alerts are
highlighted by a colouring rule based on whether the tcp.analysis.flags
tree item has been added. It seems to summarise errors under this tree
item as well as expanding on them in other parts of the analysis tree. I
guess this is easier to trap any error in a packet by checking for the
flags tree being present rather than say the retransmission tree and the
duplicate ACK tree and a whole bunch of others.
I want to be consistent with other dissectors so using mine is not
unlike using any of the others, so I think I just need to adapt what I
was doing to be more like what other dissectors do normally.
David
