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

["John Dill" <John.Dill@xxxxxxxxxxxxxxxxx>]

>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

<<winmail.dat>>