>Message: 1
>Date: Sat, 16 Sep 2017 13:38:31 +0100
>From: Peter Wu <peter@xxxxxxxxxxxxx>
>To: John Dill <John.Dill@xxxxxxxxxxxxxxxxx>,
> "wireshark-dev@xxxxxxxxxxxxx" <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] causes for losing COL_PROTOCOL or
> COL_INFO data
>Message-ID: <288553DC-6272-4581-A5E5-15B933BE7178@xxxxxxxxxxxxx>
>Content-Type: text/plain; charset=utf-8
>
>Hi John,
>
>Are your col_* functions guarded/affected by a check like if(tree) or do they depend on pinfo->fd.visited? Are the affected frames >triggering reassembly or exceptions?
Part of it is. I have a udp heuristic dissector that has a section that's kind of like this. I have to be careful with actual content, so here is pseudo-code skeletal structure.
gboolean
dissect_protocol_udp_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
{
...
data_class = tvb_get_guint8(tvb, offset);
if (data_class in list of recognized values)
{
col_add_str(pinfo->cinfo, COL_INFO, val_to_str(data_class, data_class_enum_vals, "Unknown"); /*this always works*/
...
if (tree)
{
if (data_class == XXX) {
dissect_xxx(tvb, pinfo, offset, tree);
}
if (data_class == YYY) {
...
}
...
}
...
}
}
And the COL_INFO that gets lost is in the dissect_xxx function, which has several col_append functions used. It gets lost after using a filter expression and I never get it back after that.
I've noticed this 'if (tree)' issue in a couple of the searches I've done attributed to this problem, but I don't quite understand the impact it has on dissection and populating the COL_INFO and friends column. Any explanation or pointer to how this interaction works would be greatly appreciated.
Best regards,
John Dill
P.S. Thanks to Michael for the follow up too.
