This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How can one determine within a dissector if tshark or Wireshark is being run?

0

The load time for NFSv4 captures can be reduced by up to 2.5 times by skipping the 'proto_' routines during the initial load (first pass) of the capture in Wireshark. However, if '!tree' is used to detect if this is the first pass, 'Find's for text in the Info column fails because during a Find, 'tree' is temporarily set to NULL. If instead the !pinfo->fd->flags.visited' is used, Finds work well but tshark's io,stat fails to see the NFS-related field values unless the '-2' (two pass) option of tshark is specified.

Is there a way to detect in dissect-nfs.c, via a global variable or by calling a routine, if tshark or Wireshark is being run? If so, is it also possible to detect if tshark's '-2' option was specified?

This question is marked "community wiki".

asked 29 Mar '13, 16:02

commsguy's gravatar image

commsguy
11114
accept rate: 0%

edited 29 Mar '13, 16:04


One Answer:

3

Is there a way to detect in dissect-nfs.c, via a global variable or by calling a routine, if tshark or Wireshark is being run?

No.

The load time for NFSv4 captures can be reduced by up to 2.5 times by skipping the 'proto_' routines during the initial load (first pass) of the capture in Wireshark.

Which you don't want to do if:

  1. you have a read filter;
  2. you're running Wireshark and have a color filter;
  3. you're running TShark with the -V flag or with -T fields;

etc..

The way you determine whether to construct a protocol tree is, err, umm, by looking at the tree parameter.

tree is not necessarily null on the first pass in Wireshark or TShark, and it's not necessarily non-null on subsequent passes.

However, if '!tree' is used to detect if this is the first pass, 'Find's for text in the Info column fails because during a Find, 'tree' is temporarily set to NULL.

If tree is used to control whether any columns are set - i.e., if columns are set only within if (tree) - that's a bug. Columns should be set regardless of whether tree is null or not.

And tree should not be set to NULL if you're doing a Find looking in the detail pane. It may be set to NULL if you're doing a Find looking in the Info field of the packet list pane, but that's because the protocol tree is not needed to generate the Info column.

(Also, it's not a case of "temporarily" being set to NULL. It's set to a non-null value iff the protocol tree is needed; it's not as if "non-null" is the standard setting and "null" merely a temporary special setting.)

answered 29 Mar '13, 17:41

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

edited 29 Mar '13, 19:44

Guy, Thanks. That answers my question. It is my understanding that that an 'if' operation (e.g., "if (tree) proto_tree_add_item(tree, hfindex, tvb, offset, 8, ENC_BIG_ENDIAN);") is less costly to performance than making the call to the 'proto_tree_' routine and having it return if tree is NULL because when the routine is called, its arguments have to be pushed and popped off the stack or copied to and read from registers.

In your opinion is it worthwhile to add an 'if (tree)' check to each proto_tree call or a set of such calls, or does the ugliness they cause outweigh the gains in performance afforded by them?

(30 Mar '13, 14:32) commsguy

The if (tree) takes more code (as the test is done at the call site rather than in the called routine), and the test is done in the called routine anyway, but it avoids the procedure call, so the net result may be positive. If you can bundle multiple calls under one if, there's probably a greater performance improvement.

It's worth doing it if it makes a big difference (and a 2.5x difference is big); it'd be nice to be able to avoid it, but that goes down the path of dynamic code generation (whether by interpretation of, for example, specialized bytecode, or by using something such as LLVM), which is a bigger project (worthwhile considering, but bigger).

(30 Mar '13, 20:45) Guy Harris ♦♦

Guy, I spent a great deal of time adding "if (tree)" clauses throughout the packet-nfs.c code and did as much bundling of proto_tree routines within those clauses as possible. To my surprise, there was only a 6% improvement in the load time. At least to me, it doesn't seem worth the time and effort.

(09 Apr '13, 11:55) commsguy

I went over the NFS dissector once again and found that I had only covered about half the code with "if (tree)" checks. I paid special attention to the high volume routines. I completed the work and now I'm seeing a 21% reduction in load time. For me that makes it worth the effort because with the advent of 10Gig networks, captures are becoming much larger (e.g., 2 to 4 million frames).

(10 Apr '13, 09:15) commsguy