Wireshark-dev: Re: [Wireshark-dev] Updating COL_INFO column during packet dissection
From: David Bilsby <[email protected]>
Date: Fri, 25 Oct 2013 10:25:47 +0100
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.