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

["Sultan, Hassan via Wireshark-dev" <wireshark-dev () wireshark org>]

> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces () 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-
> dev () 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-bounces () wireshark org
> <mailto:wireshark-dev-bounces () 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 <sultah () amazon com
> <mailto:sultah () 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-bounces () wireshark org
> <mailto:wireshark-dev-bounces () 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 <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- dev () wireshark org <mailto:dev () 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-request () wireshark org <mailto:wireshark-dev-
> request () 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-request () wireshark org <mailto:wireshark-
> dev-request () 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-request () wireshark org <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