Wireshark mailing list archives
Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect
From: Anders Broman <a.broman58 () gmail com>
Date: Fri, 21 Aug 2015 17:00:38 +0200
Den 21 aug 2015 16:57 skrev "Hadriel Kaplan" <the.real.hadriel () gmail com>:
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 () 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 dissectIt 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
___________________________________________________________________________ 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
Current thread:
- Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Richard Sharpe (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Jeff Morriss (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Richard Sharpe (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Anders Broman (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Hadriel Kaplan (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Anders Broman (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Richard Sharpe (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Richard Sharpe (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect mmann78 (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Jeff Morriss (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Guy Harris (Aug 21)
- Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect Richard Sharpe (Aug 21)