Den 21 aug 2015 16:57 skrev "Hadriel Kaplan" <the.real.hadriel@xxxxxxxxx>:
>
> To be clear, I think he meant: p_add_proto_data()
> (as discussed in the README.dissector section titled "Per-packet information")
>
> -hadriel
Yes, it's not so easy to look things up on your smartphone while commuting :-)
>
> On Fri, Aug 21, 2015 at 10:44 AM, Anders Broman <a.broman58@xxxxxxxxx> wrote:
> >
> > 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
> >
> >
> > ___________________________________________________________________________
> > 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
> ___________________________________________________________________________
> 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
