Wireshark · Wireshark-dev: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

["Sultan, Hassan" <sultah@xxxxxxxxxx>]

> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf
> Of Pascal Quantin
> Sent: Thursday, August 10, 2017 2:19 AM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Cc: Sake Blok <sake@xxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential
> offenders
> 
> 
> 
> Le 10 août 2017 10:56, "Stig Bjørlykke" <stig@xxxxxxxxxxxxx
> <mailto:stig@xxxxxxxxxxxxx> > a écrit :
> 
> 
> 	On Wed, Aug 9, 2017 at 7:05 PM, Pascal Quantin
> <pascal.quantin@xxxxxxxxx <mailto:pascal.quantin@xxxxxxxxx> > wrote:
> 
> 	> What about marking it as PROTO_ITEM_SET_GENERATED() as a first
> step? Tis
> 	> value is inferred from the tvb length and not a real field.
> 
> 
> 	It's not a generated field (the bytes are fetched directly from the
> 	packet without any modifications) so this would be wrong.
> 
> 
> 
> Right I missed the fact that we are also highlighting the payload in the bytes
> panel and not only indicating the length. So I agree it is not suitable.
> 
> 
> 
> 	I suppose Sake has a use case for the tcp.payload which may lead us to
> 	a hint for how to mark such fields?
> 	Because we may end up with udp.payload, ssl.payload, http.payload,
> 	sctp.payload, tftp.payload, etc. and that would mess up a bit if we
> 	don't handle them correct.  Right?

Me and Pascal have been having a discussion on https://code.wireshark.org/review/#/c/22937 on how to represent sets of fields that are related but non-contiguous.

As part of a discussion, one idea I had (and which Pascal feels won't be adopted by dissector developers) was to use ft_value to add 'linkage' between fields.
Basically add to the union inside ft_value a proto_item entry, and we could add various types specifying the type of link between fields : 
- one field is an alternate view of another
- one field is semantically linked to another (to handle the non-contiguous fields that the UI may want to display together)
etc...

To me this is something that can be added in steps to the current dissectors. Wireshark would still represent fields as it does today, and add the new way when it detects fields with the new ft_value entries. And over time as we find fields that need to be modified we transition them, up until they're all transitioned. Users should hopefully see no difference when using the UI, and we get better semantic description of the protocol for automation.

Thoughts on that approach ?

Hassan