Re: [Wireshark-dev] ASN.1 dissector Wireshark

2021-04-13 Thread Vincent Randal
Thank you. As for the second part I will post as a new separate question in
the morning.

On Mon, Apr 12, 2021 at 11:43 PM Guy Harris  wrote:

> On Apr 12, 2021, at 10:08 PM, Vincent Randal  wrote:
>
> > Thank you (John) for delving into a nice description of the overall
> process. I do have a couple more questions for you and the group:
> > 1. What is the meaning of "work is in progress to at least read all ASN1
> specifications" ???
> > I'm trying to imagine what that implies. Does it imply some dissectors
> in ./epan/dissectors/asn1 have an .asn file that is not being read?
>
> No.
>
> It implies that not all of the specifications out there that are in the
> form of text files using ASN.1's descriptive syntax can be handled by
> asn2wrs, so there are some specifications that would need manual tweaking
> to work with asn2wrs.
>
> That may be the case for some of the epan/dissectors/asn1/*/*.asn files.
>
> I don't know what all the limitations are, or whether anybody's
> *currently* working on removing any such limitations.  I don't think
> there's much being done to the specification for the ASN.1 descriptive
> syntax, so I don't think there's much that would be getting more out of
> date; it's more a question of some features in the X.whatever specs that
> isn't supported.
>
> The .cnf file's main purpose is to add additional semantics for fields
> that affects the way Wireshark dissects and displays them, over and above
> what can be expressed in the ASN.1 specification language.  For example, a
> field might be specified, in the specification language, as an OCTET
> STRING, but it might contain a blob of data with substructure *not* using
> the encoding rule for the protocol and thus *not* specifiable in the
> specification.
>
> And, even if it *could* be specified using ASN.1 specification syntax,
> doing so would mean modifying the .asn file, and if the specification is
> updated, and we wanted to update the .asn file to the latest version, we'd
> have to merge the specification changes and our changes.  That's what
> "Changing the ASN1 file is being depreciated as this creates problems when
> updating protocols." means.
> ___
> 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

Re: [Wireshark-dev] ASN.1 dissector Wireshark

2021-04-12 Thread Guy Harris
On Apr 12, 2021, at 10:08 PM, Vincent Randal  wrote:

> Thank you (John) for delving into a nice description of the overall process. 
> I do have a couple more questions for you and the group:
> 1. What is the meaning of "work is in progress to at least read all ASN1 
> specifications" ???
> I'm trying to imagine what that implies. Does it imply some dissectors in 
> ./epan/dissectors/asn1 have an .asn file that is not being read?

No.

It implies that not all of the specifications out there that are in the form of 
text files using ASN.1's descriptive syntax can be handled by asn2wrs, so there 
are some specifications that would need manual tweaking to work with asn2wrs.

That may be the case for some of the epan/dissectors/asn1/*/*.asn files.

I don't know what all the limitations are, or whether anybody's *currently* 
working on removing any such limitations.  I don't think there's much being 
done to the specification for the ASN.1 descriptive syntax, so I don't think 
there's much that would be getting more out of date; it's more a question of 
some features in the X.whatever specs that isn't supported.

The .cnf file's main purpose is to add additional semantics for fields that 
affects the way Wireshark dissects and displays them, over and above what can 
be expressed in the ASN.1 specification language.  For example, a field might 
be specified, in the specification language, as an OCTET STRING, but it might 
contain a blob of data with substructure *not* using the encoding rule for the 
protocol and thus *not* specifiable in the specification.

And, even if it *could* be specified using ASN.1 specification syntax, doing so 
would mean modifying the .asn file, and if the specification is updated, and we 
wanted to update the .asn file to the latest version, we'd have to merge the 
specification changes and our changes.  That's what "Changing the ASN1 file is 
being depreciated as this creates problems when updating protocols." means.
___
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