Hi,
Why don't use FT_BYTES type ?
On Fri, Feb 21, 2014 at 5:15 PM, John Dill <john.d...@greenfieldeng.com>wrote:
>
> >Message: 5
> >Date: Thu, 20 Feb 2014 12:33:04 -0800
> >From: Guy Harris <g...@alum.mit.edu>
> >To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
> >Subject: Re: [Wireshark-dev] displaying header field without filtering
> >Message-ID: <d47d871e-c44b-4644-9af9-9009055dc...@alum.mit.edu>
> >Content-Type: text/plain; charset=iso-8859-1
> >
> >
> >On Feb 20, 2014, at 8:12 AM, John Dill <john.d...@greenfieldeng.com>
> wrote:
> >
> >> On 19 Feb 2014, Guy Harris <g...@alum.mit.edu> wrote:
> >>
> >>> 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.
> >
> >In what fashion would those functions not achieve that goal?
>
> Before giving my answer, let me explain in more detail what my
> thought process is. It's a bit long, so I apologize I couldn't
> make it shorter. I'm also using 1.10.3 (it's annoying to get
> new versions of software installed on my workstation), so if
> there is an important behavioral change downstream, I probably
> missed it.
>
> Based on my coding tests, here is what I've observed in these given
> scenarios. Let me start with the original setup. 'proto' is a
> placeholder for the moment.
>
> \code snippet
> /* msg: Status */
> {
> &hf_Status_LRU,
> {
> "LRU",
> "proto.Status.LRU",
> FT_UINT8,
> BASE_DEC,
> VALS(proto_Status_LRU_enum_vals),
> 0x0,
> "Line Replaceable Unit",
> HFILL
> }
> },
> {
> &hf_Status_Spare,
> {
> "Spare",
> "proto.Status.Spare",
> FT_UINT8,
> BASE_HEX,
> NULL,
> 0x0,
> NULL,
> HFILL
> }
> },
> {
> &hf_Status_Status,
> {
> "Status",
> "proto.Status.Status",
> FT_UINT16,
> BASE_DEC,
> VALS(proto_Status_Status_enum_vals),
> 0x0,
> "LRU Status",
> HFILL
> }
> }
>
> ...
>
> void
> dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
> {
> proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
> proto_tree_add_item(tree, hf_Status_Spare, tvb, offset + 1, 1,
> ENC_BIG_ENDIAN);
> proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2,
> ENC_BIG_ENDIAN);
> }
> \endcode
>
> The observed behavior is the following:
>
> In the Packet Details pane, I see populated in a subtree
>
> LRU: Hf_9087D (117)
> Spare: 0x00
> Status: Failed (0)
>
> In the Filter Expression dialog, I see entries for
>
> proto.Status.LRU
> proto.Status.Spare
> proto.Status.Status
>
> The desired requirement is to provide an option to display or not
> display 'Spare: 0x00' in the Packet Details based on a preference, but
> to not populate 'proto.Status.Spare' in the Filter Expression dialog.
>
> In my effort to satisfy this requirement, I attempted the following
> implementation.
>
> \code snippet
> /* msg: Status */
> {
> &hf_Status_LRU,
> {
> "LRU",
> "proto.Status.LRU",
> FT_UINT8,
> BASE_DEC,
> VALS(proto_Status_LRU_enum_vals),
> 0x0,
> "Line Replaceable Unit",
> HFILL
> }
> },
> {
> &hf_Status_Status,
> {
> "Status",
> "proto.Status.Status",
> FT_UINT16,
> BASE_DEC,
> VALS(proto_Status_Status_enum_vals),
> 0x0,
> "LRU Status",
> HFILL
> }
> }
>
> ...
>
> void
> dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
> {
> proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
> proto_tree_add_text(tree, tvb, offset + 1, 1, "Spare: 0x%02x",
> tvb_get_guint8(tvb, offset + 1) );
> proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2,
> ENC_BIG_ENDIAN);
> }
> \endcode
>
> This accomplishes the behavior that I want, with the caveat that
> I'm using an older (perhaps obsolete?) interface, in that it still
> populates the Packet Details pane with:
>
> LRU: Hf_9087D (117)
> Spare: 0x00
> Status: Failed (0)
>
> but only has the following elements in the Filter Expression dialog
>
> proto.Status.LRU
> proto.Status.Status
>
> Now, if I use the following configuration:
>
> \code snippet
> /* msg: Status */
> {
> &hf_Status_LRU,
> {
> "LRU",
> "proto.Status.LRU",
> FT_UINT8,
> BASE_DEC,
> VALS(proto_Status_LRU_enum_vals),
> 0x0,
> "Line Replaceable Unit",
> HFILL
> }
> },
> {
> &hf_Status_Spare,
> {
> "Spare",
> "proto.Status.Spare",
> FT_UINT8,
> BASE_HEX,
> NULL,
> 0x0,
> NULL,
> HFILL
> }
> },
> {
> &hf_Status_Status,
> {
> "Status",
> "proto.Status.Status",
> FT_UINT16,
> BASE_DEC,
> VALS(proto_Status_Status_enum_vals),
> 0x0,
> "LRU Status",
> HFILL
> }
> }
>
> ...
>
> void
> dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
> {
> proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
> proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2,
> ENC_BIG_ENDIAN);
> }
> \endcode
>
> What I observed was that although no proto_tree_add_item was used
> to display the 'Spare' field, it still exists in the Filter
> Expression dialog. This led me to believe that the functions
> from the proto_tree_add family do not impact the contents of the
> Filter Expression dialog.
>
> In the Packet Details pane, I see populated in a subtree
>
> LRU: Hf_9087D (117)
> Status: Failed (0)
>
> In the Filter Expression dialog, I see entries for
>
> proto.Status.LRU
> proto.Status.Spare
> proto.Status.Status
>
> So based on my thought process, when you mention that adding
> a pair of functions in the proto_tree_add family would solve
> my problem a la
>
> proto_tree_add_spare(tree, tvb, offset, len);
> proto_tree_add_mbz(tree, tvb, offset, len);
>
> I did not get the impression that these functions would
> allow me to have the following configuration with the
> desired result:
>
> \code
> /* msg: Status */
> {
> &hf_Status_LRU,
> {
> "LRU",
> "proto.Status.LRU",
> FT_UINT8,
> BASE_DEC,
> VALS(proto_Status_LRU_enum_vals),
> 0x0,
> "Line Replaceable Unit",
> HFILL
> }
> },
> {
> &hf_Status_Spare,
> {
> "Spare",
> "proto.Status.Spare",
> FT_UINT8,
> BASE_HEX,
> NULL,
> 0x0,
> NULL,
> HFILL
> }
> },
> {
> &hf_Status_Status,
> {
> "Status",
> "proto.Status.Status",
> FT_UINT16,
> BASE_DEC,
> VALS(proto_Status_Status_enum_vals),
> 0x0,
> "LRU Status",
> HFILL
> }
> }
>
> ...
>
> void
> dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
> {
> proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
> proto_tree_add_spare(tree, hf_Status_Spare, tvb, offset + 1, 1,
> ENC_BIG_ENDIAN);
> proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2,
> ENC_BIG_ENDIAN);
> }
> \endcode
>
> In the Packet Details pane, I see populated in a subtree
>
> LRU: Hf_9087D (117)
> Spare: 0x00
> Status: Failed (0)
>
> In the Filter Expression dialog, I see entries for
>
> proto.Status.LRU
> proto.Status.Status
>
> The reason for needing 'hf_Status_Spare' in my version of the
> proto_tree_add_spare call is that I need a name for the Spare
> byte, which could be Spare, Filler_1, Not_Used2, Pad_3, etc...
>
> From the topic discussion, I got the impression that not
> putting hf_register_info entries for Spare or Reserved fields
> was considered bad practice. So if I needed to make an
> hf_register_info entry, there wasn't any flag to keep it from
> populating the Filter Expression dialog.
>
> So from my thought process, your suggestion of adding more
> proto_tree_add functions would not address the problem of not
> displaying these Spare or Reserved data elements in the Filter
> Expression dialog, since the only method to remove them that
> I've seen is to not declare them in hf_register_info.
>
> Again, if the messages were like the example above, it wouldn't
> be that big of a deal to have these Spare filter fields. The
> messages I'm dealing with range from one to several hundred data
> elements.
>
> I would appreciate any thoughts that you would have on my
> scenario.
>
> Best regards,
> John Dill
>
> ___________________________________________________________________________
> 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-requ...@wireshark.org
> ?subject=unsubscribe
>
___________________________________________________________________________
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-requ...@wireshark.org?subject=unsubscribe
