Wireshark-dev: Re: [Wireshark-dev] Undissected reserved fields
From: mmann78@xxxxxxxxxxxx
Date: Fri, 27 Feb 2015 15:32:07 -0500
To me this is a granularity/filter issue. For dissectors that I don't personally use (but want to increase filterability), I try to put as many reserved bytes into a single hf_ field, mostly out of laziness (for those that care more about the protocol to clean up/decide granularity). But it does give other users of the dissector a chance to find them with "myprotocol.reserved". Is that better than "myprotocol && _ws.reserved"? not sure. For dissectors I personally use, I still usually don't create an individual reserved field for each place one could be, so if I want to find "all" I don't have a really long filter.
You also want consistency so that all protocols use the same convention, so we don't end up with "myprotocol.reserved" for some cases and requiring "myotherprotocol && _ws.reserved" in others. Since we're already far down the "myprotocol.reserved" road now, I'd prefer to stay there rather than update all of the current reserved fields.
-----Original Message-----
From: Evan Huus <eapache@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Feb 27, 2015 2:55 pm
Subject: Re: [Wireshark-dev] Undissected reserved fields
From: Evan Huus <eapache@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Feb 27, 2015 2:55 pm
Subject: Re: [Wireshark-dev] Undissected reserved fields
Should Wireshark have an internal _ws.reserved FT_BYTES field and a proto_tree_add_reserved(tvb, offset, len) API? On Fri, Feb 27, 2015 at 2:36 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote: > +1 > > On 02/27/15 14:04, mmann78@xxxxxxxxxxxx wrote: >> >> What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with >> different abbreviations) and that's usually inclusive enough (maybe if >> I'm feeling generous setup a FT_UINT8 though FT_UINT32). If dissectors >> only have FT_UINT8 "reserved" fields, then I just add that. But I >> rarely look to give each reserved field a unique name. >> -----Original Message----- >> From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx> >> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx> >> Sent: Fri, Feb 27, 2015 1:43 pm >> Subject: Re: [Wireshark-dev] Undissected reserved fields >> >> How do we handle the case where a protocol has many reserved fields, do >> they each need an hf and a name? > > > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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
- References:
- Re: [Wireshark-dev] Undissected reserved fields
- From: Evan Huus
- Re: [Wireshark-dev] Undissected reserved fields
- Prev by Date: Re: [Wireshark-dev] Undissected reserved fields
- Next by Date: Re: [Wireshark-dev] Undissected reserved fields
- Previous by thread: Re: [Wireshark-dev] Undissected reserved fields
- Next by thread: Re: [Wireshark-dev] Undissected reserved fields
- Index(es):