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.
>> If the
>> field is reserved and not important you could just not add any item at
>> all, and skip that byte entirely...
>
> As part of the validation process for this development effort, they want to see a verbatim rendering of all the data elements and padding bytes in the Packet Details referenced against an external standards document. Eventually I'll include a preference in the plugin to visualize these Spare bytes or not.
>
> I was able to do something like the following that seems to do what I want.
>
> 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.
> Best regards,
> John Dill
>
>> On Wed, Feb 19, 2014 at 4:17 PM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
>> >
>> > I'm trying to add a header field for spare bytes in a custom dissector.
>> >
>> > Currently, I'm creating a header field for a 'Spare' data element in a
>> > 'Status' message, as shown in the example below:
>> >
>> > \code snippet
>> > {
>> > &hf_Spare,
>> > {
>> > "Spare",
>> > "msg.Status.Spare",
>> > FT_UINT8,
>> > BASE_HEX,
>> > NULL,
>> > 0x0,
>> > "Spare",
>> > HFILL
>> > }
>> > },
>> > \endcode
>> >
>> > Later I have a function that processes the 'Status' message components.
>> >
>> > void dissect_message_Status(tvbuff_t* tvb, gint offset, proto_tree *tree)
>> > {
>> > proto_tree_add_item(tree, hf_Field1, tvb, offset, 1, ENC_BIG_ENDIAN);
>> > proto_tree_add_item(tree, hf_Spare, tvb, offset + 1, 1, ENC_BIG_ENDIAN);
>> > proto_tree_add_item(tree, hf_Field2, tvb, offset + 2, 2, ENC_BIG_ENDIAN);
>> > }
>> >
>> > Visually it works great in the Packet Details pane. The issue is that I
>> > don't want to allow any filtering based on the 'Spare' data field when the
>> > user is editing a Filter Expression.
>> >
>> > What is the recommended method to handle this scenario? Do I need to remove
>> > the hf_Spare structure from the hf_register_info array and use something
>> > like proto_tree_add_text? I also see something about PROTO_ITEM_SET_HIDDEN,
>> > but it doesn't look like it applies.
>> >
>> > Thanks,
>> > 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
