[Richard Sharpe <realrichardsharpe@xxxxxxxxx>]

On Fri, Aug 21, 2015 at 7:57 AM, Hadriel Kaplan
<the.real.hadriel@xxxxxxxxx> 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@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



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)