Wireshark mailing list archives

Re: Hierarchy of fields & offsets again, more potential offenders


From: Pascal Quantin <pascal.quantin () gmail com>
Date: Thu, 10 Aug 2017 11:19:22 +0200

Le 10 août 2017 10:56, "Stig Bjørlykke" <stig () bjorlykke org> a écrit :

On Wed, Aug 9, 2017 at 7:05 PM, Pascal Quantin <pascal.quantin () gmail com>
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?


--
Stig Bjørlykke
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.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:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: