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

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

>Message: 2
>Date: Wed, 19 Feb 2014 19:03:57 -0500
>From: Evan Huus <eapache@xxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] displaying header field without filtering
>Message-ID:
>	<CAOYNdEKR4BVCBfmFG8a2=98U1CCXyCzT5j=z10Pdrea4Csb+wA@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Wed, Feb 19, 2014 at 5:57 PM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
>>>Message: 6
>>> Date: Wed, 19 Feb 2014 17:24:11 -0500
>>> From: Evan Huus <eapache@xxxxxxxxx>
>>> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>>> Subject: Re: [Wireshark-dev] displaying header field without filtering
>>>         capability
>>> Message-ID:
>>>         <CAOYNdEKkYZmjZUZ28tjJdgKnO+_qvEu2YYMOCXmAPZhHbBKO=A@xxxxxxxxxxxxxx>
>>> 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@xxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] displaying header field without filtering
>Message-ID: <DF61D62C-1157-4CB2-BA03-8121C4DEAFCC@xxxxxxxxxxxx>
>Content-Type: text/plain; charset=us-ascii
>
>On Feb 19, 2014, at 4:03 PM, Evan Huus <eapache@xxxxxxxxx> 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>>