ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: "John Dill" <John.Dill@xxxxxxxxxxxxxxxxx>
Date: Wed, 19 Feb 2014 17:57:25 -0500
>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.

> 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"?

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

<<winmail.dat>>