Wireshark-dev: Re: [Wireshark-dev] Bug in Wireshark Display filter engine caused by optimizatio
On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
> On 08/21/15 10:09, Richard Sharpe wrote:
>>
>> Hi folks,
>>
>> Below are my findings on the problem I mentioned earlier under the
>> title of Is this a bug in the display filter engine or something I
>> have done wrong.
>>
>> The problem is that unless the display filter explicitly mentions a
>> field it will usually be optimized out of the proto tree.
>>
>> I would like more input on how to solve this problem.
>>
>> One approach I can think if is that the Header Field abbrev field can
>> include fields that it depends on, eg:
>>
>> {&hf_ieee80211_ff_dmg_params_bss,
>> {"BSS Type", "wlan.dmg_params.bss(radiotap.channel.freq)",
>> FT_UINT8, BASE_DEC, VALS(bss_type), 0x03,
>> NULL, HFILL }},
>>
>> Where the field in parens specifies what other fields this on might
>> depend on. The filter parser would have to parse them out and include
>> them in the array of fields of interest.
>>
>> However, I wonder if there is an easier way.
>>
>> This only seems to be a problem for protocols that depend in some way
>> on protocols above them.
>
>
> Sorry, I had marked your earlier emails as something to come back
> to--because I didn't have time, on first reading them, to investigate or
> think about it.
>
> It appears that the 802.11 dissector calls
> proto_tree_traverse_post_order()/is_80211ad() in order find the value of a
> field (hf) named "Channel frequency"; if the value is one of the AD
> frequencies then the dissector, well, treats it as AD.
>
> Isn't this backwards from how Wireshark normally does things? Shouldn't we
> be storing the channel frequency somewhere (historically that would be in
> pinfo though there's been some effort to get stuff out of there) so later
> dissectors can (easily) get the value?
>
> (Regardless I think you're fundamentally right: because we fake (most) items
> proto_tree_traverse_post_order() can't work unless tree is set.)
Right, this would be a better approach if people are not too
uncomfortable in storing this piece of info.
Thus, the radiotap (and perhaps one other in the tree that seems to
know the channel frequency) could store it as a value in the pinfo.
These changes would be much less intrusive in the rest of the
infrastructure and confined to the ieee80211 series of dissectors.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
