[Paul Offord <Paul.Offord@xxxxxxxxxxxx>]

I have checked the operation of the LUA and the scenario is different again.  The LUA dissector (dissect_lua) is called like this:

 

  static int

  call_dissector_through_handle(dissector_handle_t handle, tvbuff_t *tvb,

                          packet_info *pinfo, proto_tree *tree, void *data)

  {

 

       [lines removed]

 

       if (handle->protocol != NULL) {

             pinfo->current_proto =

                    proto_get_protocol_short_name(handle->protocol);

       }

 

       len = (*handle->dissector)(tvb, pinfo, tree, data);

 

 

At the time of the call the tree value is NULL.  I then step into the called function, which is:

 

  int dissect_lua(tvbuff_t* tvb, packet_info* pinfo, proto_tree* tree, void* data _U_) {

 

When I arrive in this function, suddenly I have a valid tree value.  I guess I don’t understand how pointers to functions work, and that the function I’m pointing to somehow overrides the tree value.

 

Anyway, I don’t think this helps with the decision regarding the code in tshark.  This is obviously working in a different way.

 

I’m going to chance my luck and log a Bugzilla report.

 

Best regards…Paul

 

From: Paul Offord
Sent: 10 February 2017 11:25
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: RE: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap defined

 

Hi Anders,

 

I agree regarding performance.  And we don’t need to force the protocol tree each time – just when a tap has been registered.

 

The interesting thing is that the LUA version of TRANSUM works fine with tshark.  I haven’t had chance yet to check why, or what the change is to the code path.

 

Best regards…Paul

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Anders Broman
Sent: 10 February 2017 09:54
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap defined

 

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
______________________________________________________________________

______________________________________________________________________

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
______________________________________________________________________