Wireshark · Wireshark-dev: Re: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap defined

[Anders Broman <anders.broman@xxxxxxxxxxxx>]

Hi,

I guess the idea in tshark for the 2 pass analysis is not to create a tree on the first pass to increase performance and you probably just want the result of the

Final pass over the file where hopefully all needed information is available. I suppose we require all code to handle a NULL tree.

 

Regards

Anders

 

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Paul Offord
Sent: den 10 februari 2017 09:16
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap defined

 

Hi,

 

I’ve been investigating a problem with transum, a post-dissector.  If you run tshark with transum it throws Access Violations.  I’m starting tshark with these arguments:

 

-2 -q -ta -o transum.tsumenabled:TRUE -T fields -E separator=, -E quote=d -E header=y -e frame.number -e _ws.col.Time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e _ws.col.Info -r "C:\traces\Contoso_01\web01\web01_00001_20161012151754.pcap"

 

NB: The -2 flag indicates that tshark should make two passes.

 

The reason transum throws Access Violations is because the dissect_transum dissector is called on the first pass with a NULL proto_tree pointer.  I’ll add defensive code to transum to avoid the Access Violation but there is an underlying problem.

 

It's normal for a dissector to be called with a NULL proto_tree pointer on the first pass *unless* a tap has been registered.  Transum registers a tap, and so when using Wireshark, each first-pass call to dissect_transum includes a pointer to a proto_tree.  With tshark, even though the tap is registered the proto_tree pointer is still NULL.

 

When running Wirehsark, the decision to create a proto_tree is made in cf_read of file.c with this code:

 

  /* Get the union of the flags for all tap listeners. */

  tap_flags = union_of_tap_listener_flags();

  create_proto_tree =

    (dfcode != NULL || have_filtering_tap_listeners() || (tap_flags & TL_REQUIRES_PROTO_TREE));

 

  [lines removed from listing]

 

  epan_dissect_init(&edt, cf->epan, create_proto_tree, FALSE);

 

 

When running tshark with the parameters above the decision to create a proto_tree is made in load_cap_file(…) function of tshark.c with this code:

 

  /* Do we have any tap listeners with filters? */

  filtering_tap_listeners = have_filtering_tap_listeners();

 

  /* Get the union of the flags for all tap listeners. */

  tap_flags = union_of_tap_listener_flags();

 

  if (perform_two_pass_analysis) {

    frame_data *fdata;

 

   [lines removed from listing]

 

    if (do_dissection) {

       gboolean create_proto_tree = FALSE;

 

      /* If we're going to be applying a filter, we'll need to

         create a protocol tree against which to apply the filter. */

      if (cf->rfcode || cf->dfcode)

        create_proto_tree = TRUE;

 

      tshark_debug("tshark: create_proto_tree = %s", create_proto_tree ? "TRUE" : "FALSE");

 

      /* We're not going to display the protocol tree on this pass,

         so it's not going to be "visible". */

      edt = epan_dissect_new(cf->epan, create_proto_tree, FALSE);

    }

 

 

Neither, cf->rfcode or cf->dfcode are true and so the tree isn’t created.  I think the code should be:

 

      if (cf->rfcode || cf->dfcode || filtering_tap_listeners)

        create_proto_tree = TRUE;

 

 

Am I right?  Have I misunderstood something about tshark?

 

Thanks and regards…Paul

______________________________________________________________________

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________