Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-08 Thread Sultan, Hassan via Wireshark-dev 


> -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 
> 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  d...@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
>  ] On Behalf Of Sultan, Hassan
> via Wireshark-dev
>   Sent: Wednesday, August 02, 2017 2:09 PM
>   To: Developer support list for Wireshark   >
> 
>   Cc: Sultan, Hassan   >
>   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  d...@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
>   > 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
> 
>   >
>   > 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
>

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-08 Thread Alexis La Goutte 
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 
> Cc: Sultan, Hassan 
> 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 
> > 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
> >  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 
> > 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 
> 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 
> 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 
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

[Wireshark-dev] TCAP SRT analysis

2017-08-08 Thread Conall Prendergast 
Hi All,

The TCAP SRT analysis is broken in 2.2.8 and 2.4. I have written a bug on
it here .

This was broken in this
 recent change,
which does fix another broken issue in v2.2.7.

Regards,
Conall

-- 


3 Custom House Plaza | IFSC | Dublin | D01 VY76 | Ireland | Tel.  +353 (1) 
291 0138 | Fax. +353 (1) 291 0131 

Asia Office - Suite 12.03, Level 12, Centrepoint North | Mid Valley City | 
59200 Kuala Lumpur | Malaysia | Tel. +603 2201 3375 

The information contained in this e-mail transmission is confidential and 
may be privileged. It is for the intended recipient only. Any views or 
opinions present are solely those of the author. If you are not the 
intended recipient you must not use, disclose, distribute, copy, print or 
rely on this e-mail. If you have received this e-mail in error, please 
immediately notify us by telephone at 353-1-2910138 or e-mail 
mailad...@anam.com and delete the email from your system
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] checkapi prefs

2017-08-08 Thread Michael Mann via Wireshark-dev 

See https://code.wireshark.org/review/22974
 
This was added to help developer mistakes, but maybe there is a legitimate 
reason? (or regex in checkAPI needs tweeking)
 
 
-Original Message-
From: Dario Lombardo 
To: Developer support list for Wireshark 
Sent: Aug 8  5:33 am
Subject: [Wireshark-dev] checkapi prefs



I've got this error from checkAPI_epan target:



prefs.c: error: found these preference variables used in more than one 
prefs_register_*_preference:
guint *var, const char **var, , range_t **var



I can't figure out what does it mean. Can anyone help?

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] checkapi prefs

2017-08-08 Thread Ahmad Fatoum 
prefs_register_*_preference populates a variable with a user-supplied
value. And having more than one preference populate the same variable is
usually not what you want.
But the actual definitions of the function do just that: They use the same
variable name and similar types for the variable.

I will submit a fix shortly. Thanks for reporting.

Cheers,
Ahmad


On Tue, Aug 8, 2017 at 11:33 AM, Dario Lombardo  wrote:

> I've got this error from checkAPI_epan target:
>
> prefs.c: error: found these preference variables used in more than one
> prefs_register_*_preference:
> guint *var, const char **var, , range_t **var
>
> I can't figure out what does it mean. Can anyone help?
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> 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 
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

[Wireshark-dev] checkapi prefs

2017-08-08 Thread Dario Lombardo 
I've got this error from checkAPI_epan target:

prefs.c: error: found these preference variables used in more than one
prefs_register_*_preference:
guint *var, const char **var, , range_t **var

I can't figure out what does it mean. Can anyone help?
___
Sent via:Wireshark-dev mailing list 
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