To be clear, I think he meant: p_add_proto_data()
(as discussed in the README.dissector section titled "Per-packet information")
-hadriel
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
