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 <[email protected]>
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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Anders Broman
Sent: 10 February 2017 09:54
To: Developer support list for Wireshark
<[email protected]<mailto:[email protected]>>
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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Paul Offord
Sent: den 10 februari 2017 09:16
To: Developer support list for Wireshark
<[email protected]<mailto:[email protected]>>
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
_________________________________________________________________________________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
