Wireshark mailing list archives
Re: Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect
From: Hadriel Kaplan <the.real.hadriel () gmail com>
Date: Fri, 21 Aug 2015 10:57:09 -0400
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 () 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
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)