Wireshark · Wireshark-dev: Re: [Wireshark-dev] Is this a bug in display filter engine or something I have done wrong?

[Richard Sharpe <realrichardsharpe@xxxxxxxxx>]

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.

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