> -----Original Message----- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf > Of Alexis La Goutte > Sent: Tuesday, August 08, 2017 2:09 PM > To: Developer support list for Wireshark <wireshark-dev@wireshark.org> > Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more > potential > offenders > > > > On Tue, Aug 8, 2017 at 12:29 AM, Sultan, Hassan via Wireshark-dev <wireshark- > d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > Hi Hasan, > > > Can you share your tools ? i can be add to wireshark for found some > violation/error...
I am hoping to do exactly that at some point, it's still in early stages at this point though. > > Coming back on this and how to solve it, here's a suggestion I have, let > me know what you guys think : > > - Whenever a field is really a helper rather than the actual parsed data > (an alternate representation of data in the packet for example, here > tcp.payload > would be the alternate representation of the data parsed in the following > layers) > mark the field as FI_GENERATED, or create a new flag for helper fields and > mark > them as such > > > It is a idea but GENERATED it is not the good field.. > > it is not possible to ignore some hf on your tools ? It would be possible but not scalable. People add new dissectors to Wireshark or modify them all the time, and as a result keeping static lists is not something that works long term. We'd need an automated way of recognizing such fields. Hence the idea of a flag... Ultimately I think it would be really super valuable to be able to differentiate fields that are a direct mapping of what is in the packet (in terms of offset/length/datatype) and those that are some interpretation of packet content. > In the case here, tcp.payload would stay under tcp, but flagged as > FI_GENERATED or FI_HELPER (or whatever we'd call the flag). The NTLMSSP > cases further in the list I gave has a similar case, where an FT_STRING field > is > present as a helper so the person looking at the parsed packet immediately > sees > what the offset/length of the string correspond to, but the string it > represents is > data located in a very different position in the packet and which already has > another field representing it. > > > > NTMLSSP (and other dissector like GQUIC) use a map-value entry for field > > and yes, it is a complicated for display this case on Wireshark... and i > don't have > solution... > > > > Adding a flag has the advantage that automation can easily identify > these fields and act accordingly (for example to ignore them). > > Thoughts ? > > -----Original Message----- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org > <mailto:wireshark-dev-boun...@wireshark.org> ] On Behalf Of Sultan, Hassan > via Wireshark-dev > Sent: Wednesday, August 02, 2017 2:09 PM > To: Developer support list for Wireshark <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org> > > > Cc: Sultan, Hassan <sul...@amazon.com > <mailto:sul...@amazon.com> > > Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more > potential offenders > > So if this needs to be fixed, but we can't change the tcp protocol > length, > nor move tcp.payload to the top-level, what are the options left ? > > My personal view is towards being able to process the information in an > automated manner. I'd personally strive for some type of consistency, but I'm > not sure what the options are here. > > > -----Original Message----- > > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org > <mailto:wireshark-dev-boun...@wireshark.org> ] On > > Behalf Of Stig Bjørlykke > > Sent: Wednesday, August 02, 2017 1:24 PM > > To: Developer support list for Wireshark <wireshark- > d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > > > Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more > > potential offenders > > > > On Wed, Aug 2, 2017 at 10:03 PM, Sultan, Hassan via Wireshark-dev > > <wireshark- d...@wireshark.org <mailto:d...@wireshark.org> > > wrote: > > > Regarding tcp.payload, I don't think tcp.payload in itself has any > > > problems. I > > think the issue lies in tcp showing a length of 32 only, even though > > it has tcp.payload as its child. > > > > The tcp.payload field was recently added, have a look at > > https://code.wireshark.org/review/22374 > <https://code.wireshark.org/review/22374> > > > > I do agree that this is displayed wrong and should be fixed. > > Increasing the length of the TCP header would be wrong because the > > payload is dissected by upper protocols and does belong with the TCP > > header. Putting it at top level would also be wrong because it's not > a > protocol. > > > > > > -- > > Stig Bjørlykke > > > _________________________________________________________________ > > __________ > > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org> > > > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark- > dev <https://www.wireshark.org/mailman/options/wireshark-dev> > > > > mailto:wireshark-dev-requ...@wireshark.org <mailto:wireshark-dev- > requ...@wireshark.org> ?subject=unsubscribe > __________________________________________________________ > _________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org> > > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark- > dev <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org > <mailto:wireshark- > dev-requ...@wireshark.org> ?subject=unsubscribe > __________________________________________________________ > _________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org> > > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark- > dev <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org > <mailto:wireshark- > dev-requ...@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-requ...@wireshark.org?subject=unsubscribe
