Hi,
I noticed a while back that the "Expert Info" dialog sometimes wasn't
catching items that appeared in "Expert Info Composite".
I'm currently using the attached patch, i.e. at the end of
expert_dlg_init() I call:
cf_redissect_packets(&cfile);
instead of
cf_retap_packets(&cfile, FALSE);
This redissects packets with 'tree' set. This matches what
expert_comp_dlg.c does - it notes in a comment:
/* We currently cannot just retap the packets because we will not be
able
* to acquire the fvalue data. The expert items would already have been
* cleared and we will not be able to perform any filtering of data.
* So we force a redissect so that all data is valid.
* If someone can figure out why the expert_item value is null when
* performing a retap then this call to
* cf_redissect_packets(&cfile);
* can be changed to...
* cf_retap_packets(&cfile, NULL);
* which would be much faster.
*/
Should both tap listeners call cf_redissect_packets()?
OR:
Should dissectors avoid calling expert_add_info_format() on paths only
taken with a non-null tree? This would mean in some cases going deeper
into the packet with a NULL tree than is necessary to set the info column...
Regards,
Martin
Index: gtk/expert_dlg.c
===================================================================
--- gtk/expert_dlg.c (revision 18734)
+++ gtk/expert_dlg.c (working copy)
@@ -578,8 +578,8 @@
gtk_widget_show_all(etd->win);
window_present(etd->win);
-
- cf_retap_packets(&cfile, FALSE);
+
+ cf_redissect_packets(&cfile);
}
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
