Wireshark-dev: Re: [Wireshark-dev] Bug in Wireshark Display filter engine caused by optimizatio
Den 21 aug 2015 16:37 skrev "Richard Sharpe" <realrichardsharpe@xxxxxxxxx>:
>
> 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 dissect
It should probably be stored using p_add_packet_data () rather than pinfo IMHO.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
