Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Is this a bug in display filter engine or something I have d

From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
Date: Tue, 18 Aug 2015 21:08:05 -0700
On Tue, Aug 18, 2015 at 9:04 PM, Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
> On Tue, Aug 18, 2015 at 7:47 PM, Richard Sharpe
> <realrichardsharpe@xxxxxxxxx> wrote:
>> On Tue, Aug 18, 2015 at 5:18 AM, Gilbert Ramirez <gram@xxxxxxxxxxxxxxx> wrote:
>>> Hi Richard.
>>>
>>> You can use the 'dftest' executable that is built along with Wireshark to
>>> convert a display filter string to the byte-code used for the Display Filter
>>> Virtual Machine. Do that for for "wlan.dmg_params.bss == 1" and compare that
>>> to the output for a similar display filter for another field that is also
>>> FT_UINT8.
>>>
>>> I suspect they will be the same; if so, it wouldn't be an issue within the
>>> display filter code.
>>>
>>> Is there any possibility that add_ff_dmg_params() isn't being called or
>>> isn't adding dmg_params to the proto_tree in some cases?
>>
>> So, that is what is happening. When the filter engine is called, isDMG
>> evals to 0, so add_ff_dmg_params is not called.
>>
>> Now, why is that?
>>
>> In dissect_ieee80211_common we have this code:
>>
>>   gboolean         isDMG = (tree == NULL) ? FALSE :
>>
>> proto_tree_traverse_post_order(proto_tree_get_root(tree),
>>                                   is_80211ad, NULL);
>>
>> (reformatted for readability).
>>
>> Printfs establish that tree is not NULL when this statement is called,
>> so it would seem that the proto_tree_traverse_post_order failed during
>> filtering.
>>
>> is_80211ad is a function that does a number of tests, anyone of which
>> could fail, I guess.
>
> It seems that when the filter engine runs and is interested in a
> specific protocol, it does not dissect the protocols above that
> protocol, because the fields in the IEEE 802.11 Radiotap Capture
> header, which contains the relevant Channel frequency field, were not
> there.

OK, I appear to have confirmed this by using the following filter:

(wlan.dmg_params.bss == 1) && (radiotap.channel.freq == 60480)

Is the message here that making things conditional on fields from
protocols above you makes those things not filterable?

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)