On Wed, Feb 19, 2014 at 5:57 PM, John Dill <john.d...@greenfieldeng.com> wrote:
>>Message: 6
>> Date: Wed, 19 Feb 2014 17:24:11 -0500
>> From: Evan Huus <eapa...@gmail.com>
>> To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
>> Subject: Re: [Wireshark-dev] displaying header field without filtering
>> capability
>> Message-ID:
>>
>> <CAOYNdEKkYZmjZUZ28tjJdgKnO+_qvEu2YYMOCXmAPZhHbBKO=a...@mail.gmail.com>
>> 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.d...@greenfieldeng.com>
>> 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@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
