[David Bilsby <dbilsby@xxxxxxxxxxxxxx>]

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