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.)
