Wireshark-dev: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offender
> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf
> Of Alexis La Goutte
> Sent: Tuesday, August 08, 2017 2:09 PM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx> > 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@xxxxxxxxxxxxx
> <mailto:wireshark-dev-bounces@xxxxxxxxxxxxx> ] On Behalf Of Sultan, Hassan
> via Wireshark-dev
> Sent: Wednesday, August 02, 2017 2:09 PM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx
> <mailto:wireshark-dev@xxxxxxxxxxxxx> >
>
> Cc: Sultan, Hassan <sultah@xxxxxxxxxx
> <mailto:sultah@xxxxxxxxxx> >
> 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@xxxxxxxxxxxxx
> <mailto:wireshark-dev-bounces@xxxxxxxxxxxxx> ] On
> > Behalf Of Stig Bjørlykke
> > Sent: Wednesday, August 02, 2017 1:24 PM
> > To: Developer support list for Wireshark <wireshark-
> dev@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx> >
> > 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@xxxxxxxxxxxxx <mailto:dev@xxxxxxxxxxxxx> >
> 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@xxxxxxxxxxxxx
> <mailto:wireshark-dev@xxxxxxxxxxxxx> >
> > 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@xxxxxxxxxxxxx <mailto:wireshark-dev-
> request@xxxxxxxxxxxxx> ?subject=unsubscribe
> __________________________________________________________
> _________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx
> <mailto:wireshark-dev@xxxxxxxxxxxxx> >
> 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@xxxxxxxxxxxxx <mailto:wireshark-
> dev-request@xxxxxxxxxxxxx> ?subject=unsubscribe
> __________________________________________________________
> _________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx
> <mailto:wireshark-dev@xxxxxxxxxxxxx> >
> 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@xxxxxxxxxxxxx <mailto:wireshark-
> dev-request@xxxxxxxxxxxxx> ?subject=unsubscribe
>
