Wireshark mailing list archives
Re: displaying header field without filtering
From: Evan Huus <eapache () gmail com>
Date: Wed, 19 Feb 2014 19:03:57 -0500
On Wed, Feb 19, 2014 at 5:57 PM, John Dill <John.Dill () greenfieldeng com> wrote:
Message: 6 Date: Wed, 19 Feb 2014 17:24:11 -0500 From: Evan Huus <eapache () 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 DillOn Wed, Feb 19, 2014 at 4:17 PM, John Dill <John.Dill () 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-request () 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-request () wireshark org?subject=unsubscribe
Current thread:
- Re: displaying header field without filtering John Dill (Feb 19)
- Re: displaying header field without filtering Evan Huus (Feb 19)
- Re: displaying header field without filtering Guy Harris (Feb 19)
- duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Pascal Quantin (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: displaying header field without filtering Evan Huus (Feb 19)
- <Possible follow-ups>
- Re: displaying header field without filtering John Dill (Feb 20)
- Re: displaying header field without filtering Guy Harris (Feb 20)
- Re: displaying header field without filtering John Dill (Feb 21)
- Re: displaying header field without filtering Alexis La Goutte (Feb 21)
- Re: displaying header field without filtering Guy Harris (Feb 21)
- Re: displaying header field without filtering Jeff Morriss (Feb 24)