On Tue, Aug 8, 2017 at 12:29 AM, Sultan, Hassan via Wireshark-dev < wireshark-dev@wireshark.org> wrote: Hi Hasan,
Can you share your tools ? i can be add to wireshark for found some violation/error... 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 ? > > 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] 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> > Cc: Sultan, Hassan <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] On > > Behalf Of Stig Bjørlykke > > Sent: Wednesday, August 02, 2017 1:24 PM > > To: Developer support list for Wireshark <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> 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 > > > > 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> > > 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 > ____________________________________________________________ > _______________ > 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 > ____________________________________________________________ > _______________ > 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 >
___________________________________________________________________________ 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
