Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect

[Richard Sharpe <realrichardsharpe () gmail com>]

On Fri, Aug 21, 2015 at 7:57 AM, Hadriel Kaplan
<the.real.hadriel () gmail com> wrote:
> To be clear, I think he meant: p_add_proto_data()
> (as discussed in the README.dissector section titled "Per-packet information")

Hmmm, but that does require that I have the proto handle for the layer
that added the information, which is not so great if it could be added
by multiple layers.

> -hadriel
>
> On Fri, Aug 21, 2015 at 10:44 AM, Anders Broman <a.broman58 () gmail com> wrote:
> > Den 21 aug 2015 16:37 skrev "Richard Sharpe" <realrichardsharpe () gmail com>:
> > > On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss <jeff.morriss.ws () gmail com>
> > > 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 () wireshark org>
> > > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > >
> > > mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> >              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe