Wireshark mailing list archives
Re: displaying header field without filtering
From: "John Dill" <John.Dill () greenfieldeng com>
Date: Thu, 20 Feb 2014 11:12:51 -0500
Message: 2 Date: Wed, 19 Feb 2014 19:03:57 -0500 From: Evan Huus <eapache () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] displaying header field without filtering Message-ID: <CAOYNdEKR4BVCBfmFG8a2=98U1CCXyCzT5j=z10Pdrea4Csb+wA () mail gmail com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 5:57 PM, John Dill <John.Dill () greenfieldeng com> wrote:Message: 6 Date: Wed, 19 Feb 2014 17:24:11 -0500 From: Evan Huus <eapache () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] displaying header field without filtering capability Message-ID: <CAOYNdEKkYZmjZUZ28tjJdgKnO+_qvEu2YYMOCXmAPZhHbBKO=A () mail gmail com> Content-Type: text/plain; charset=ISO-8859-1 You could use proto_tree_add_text but that is strongly recommended against. Why do you want to explicitly disallow filtering?Because there are several dozen messages (in the first subset I'm working on, there are several hundred messages total) with any number of arbitrary placed Spare bytes to make some data elements in these messages aligned at multiples of 4, and these Spare entries would clog up a decent amount of space in the filter expression dialog.You can reuse a single "spare" field for all of these bytes, and they would only cause a single entry in the filter expression dialog. I suspect this is the best answer.
This could be feasible. Unfortunately, the naming convention for these spare bytes are mixed since these message groups were developed across several teams and there was no cross-team standardization. What this means is that there are several naming conventions for "Spare" bytes. Spare, Spare1, Spare2, ... Filler_1, Filler_2, ... Not_Used, Not_Used2, ... Pad, Pad2, Pad3, ... Pad_1, Pad_2, Pad_3, ... Some of these fields are 1 or 2 bytes in length, which means that in message 'A', "Spare" is 1 byte, but in message 'B' "Spare" is 2 bytes. On top of this, there are also reserved fields which are applicable for some M out of N platforms depending on installed avionics, so having the ability to "disable" the filtering of these data elements for different configurations would be very useful. At the moment I'm working on one platform, but this could eventually extend to several platforms with potentially multiple configurations as they get upgrades over time. As such, I currently use something like "protocol.message.data_element" for the 'abbrev' member of 'struct header_field_info'. Eventually, these header_field_info structures will be code generated. To give a little more perspective, my audience for using the Wireshark tool are not network protocol experts. They are not even familiar with the data that is in these messages. They are test engineers that want to load a capture file, browse through what data is available (I'm using the Filter Expression dialog as that location), and then search or filter based on that data displayed in human readable text (for enums/booleans) or integer/floating point data converted to engineering units. Seeing all the Spare elements in the packets is important for the validation part of the project. When the dissector plugin has been deployed, the test engineers want the option to not see Spare or Reserved data elements to reduce noise and the potential for confusion if one happens to pick a Reserved data element. [snip]
proto_tree_add_text(tree, tvb, offset + 1, 1, "Spare: 0x%02x", tvb_get_guint8(tvb, offset + 1)); Can you explain in more detail why this is "strongly recommended against"?It was at one point (long ago before wireshark had filtering) the default API, so it is in a lot of old code. People often use it by mistake when they *want* filterable items. It's also not quite as abstract, since the data must be fetched separately, and the offset must be specified twice.
Thanks for the history.
Message: 3 Date: Wed, 19 Feb 2014 16:45:25 -0800 From: Guy Harris <guy () alum mit edu> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] displaying header field without filtering Message-ID: <DF61D62C-1157-4CB2-BA03-8121C4DEAFCC () alum mit edu> Content-Type: text/plain; charset=us-ascii On Feb 19, 2014, at 4:03 PM, Evan Huus <eapache () gmail com> wrote:It was at one point (long ago before wireshark had filtering) the default API, so it is in a lot of old code. People often use it by mistake when they *want* filterable items. It's also not quite as abstract, since the data must be fetched separately, and the offset must be specified twice.If it's deemed too-inconvenient to require that all spare fields/padding/etc. be given some named field or fields, perhaps we should have a proto_tree_add_spare(tree, tvb, offset, len); API, perhaps with a global preference item to indicate whether those fields should be displayed in the protocol tree or not; if displayed, they'll be shown as the raw hex data. An additional API might be proto_tree_add_mbz(tree, tvb, offset, len); which is similar, but doesn't display the value unless it's non-zero, *and* adds an expert info item if it's non-zero.
Those functions sound very reasonable for controlling the display of spare bytes, but I'm also greedy enough to want some way to kick these Spare and Reserved header_field_info structures out of the Filter Expression dialog. I don't know if it's a terrible idea, but one option would be to add a bit flag to 'type'. \code { &hf_msg1_Spare, { "Spare", "proto.msg1.Spare", FT_UINT8 | FT_NO_FILTER, BASE_HEX, NULL, 0x0, "Spare", HFILL } }, { &hf_msg2_Spare, { "Spare", "proto.msg2.Spare", FT_UINT16 | FT_NO_FILTER, BASE_HEX, NULL, 0x0, "Spare", HFILL } }, { &hf_msg2_Reserved_Field, { "Reserved_Field", "proto.msg2.Reserved_Field", FT_UINT32 | FT_NO_FILTER, BASE_DEC, NULL, 0x0, "Reserved", HFILL } }, \endcode When you go to register the header fields in 'proto_register_field_array', you ignore populating the Filter Expression dialog for any entries with the FT_NO_FILTER (or whatever you would want to call it) bit set. It would make my eventual code generation step a touch easier. There's probably a better way to do it, and if it's not in Wireshark's interests, I would be willing to maintain my own patch. Thanks for the discussion. It'll help me better explain why or why not things can be done in Wireshark to the people reviewing the requirements. Best regards, John Dill
<<winmail.dat>>
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: displaying header field without filtering John Dill (Feb 19)
- Re: displaying header field without filtering Evan Huus (Feb 19)
- Re: displaying header field without filtering Guy Harris (Feb 19)
- duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Pascal Quantin (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: displaying header field without filtering Evan Huus (Feb 19)
- <Possible follow-ups>
- Re: displaying header field without filtering John Dill (Feb 20)
- Re: displaying header field without filtering Guy Harris (Feb 20)
- Re: displaying header field without filtering John Dill (Feb 21)
- Re: displaying header field without filtering Alexis La Goutte (Feb 21)
- Re: displaying header field without filtering Guy Harris (Feb 21)
- Re: displaying header field without filtering Jeff Morriss (Feb 24)
- Re: displaying header field without filtering John Dill (Feb 21)
- Re: displaying header field without filtering John Dill (Feb 24)