The reason why the expert_item value is null when performing a retap is

that a retap doesn't build the protocol tree unless there's a tap with a
filter; presumably "the expert_item value" refers to the item to which
expert information is being attached.

However, if there's no protocol item, the only thing
expert_add_info_format() doesn't do is set the severity and group for a
protocol item, but the expert info composite dialog doesn't appear to
look at that.

Thus, it appears we can just use cf_retap_packets(); do so, as it's
faster.


git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@28270 f5534014-38df-0310-8fa8-9805f1628bb7

1 files changed, 17 insertions, 15 deletions

diff --git a/gtk/expert_comp_dlg.c b/gtk/expert_comp_dlg.c
index 3842724c15..9a19ce996d 100644
--- a/gtk/expert_comp_dlg.c
+++ b/gtk/expert_comp_dlg.c
@@ -348,22 +348,24 @@ expert_comp_init(const char *optarg _U_, void* userdata _U_)
     gtk_widget_show_all(ss->win);
     window_present(ss->win);
 
-    /* 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.
+    /*
+     * At least at present, the only information the tap listener appears
+     * to care about is available regardless of whether the protocol tree
+     * is being built, so we don't appear to need to have the protocol
+     * tree built.
+     *
+     * This means we can use cf_retap_packets(), even though it will only
+     * build the protocol tree if at least one tap has a filter in place.
+     * cf_retap_packets() is faster than cf_redissect_packets(), as it
+     * assumes we didn't change anything that would cause any packets to
+     * dissect differently, and thus doesn't redo the packet display.
      */
-    cf_redissect_packets(&cfile);
-	/* This will bring up the progress bar
-	 * Put our window back in front
-	 */
-	gdk_window_raise(ss->win->window);
+    cf_retap_packets(&cfile, FALSE);
+
+    /* This will bring up the progress bar
+     * Put our window back in front
+     */
+    gdk_window_raise(ss->win->window);
 }
 
 void