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

[Alexis La Goutte <alexis.lagoutte () gmail com>]

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-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>
> Cc: Sultan, Hassan <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] 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- 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
> >
> > 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-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
> ____________________________________________________________
> _______________
> 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