Wireshark · Wireshark-dev: Re: [Wireshark-dev] displaying header field without filtering

[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

Hi,

Why don't use FT_BYTES type ?

On Fri, Feb 21, 2014 at 5:15 PM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:

>Message: 5
>Date: Thu, 20 Feb 2014 12:33:04 -0800

>From: Guy Harris <guy@xxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] displaying header field without filtering

>Message-ID: <D47D871E-C44B-4644-9AF9-9009055DCF5A@xxxxxxxxxxxx>
>Content-Type: text/plain; charset=iso-8859-1

>
>
>On Feb 20, 2014, at 8:12 AM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
>
>> On 19 Feb 2014, Guy Harris <guy@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe