Den 21 aug 2015 16:57 skrev "Hadriel Kaplan" <[email protected]>: > > 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 <[email protected]> wrote: > > > > Den 21 aug 2015 16:37 skrev "Richard Sharpe" < [email protected]>: > >> > >> On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss < [email protected]> > >> 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 <[email protected]> > >> Archives: https://www.wireshark.org/lists/wireshark-dev > >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > >> > >> mailto:[email protected]?subject=unsubscribe > > > > > > ___________________________________________________________________________ > > Sent via: Wireshark-dev mailing list <[email protected]> > > Archives: https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:[email protected] ?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
