CSN.1 [Re: Remaining Wireshak stuff during FOSDEM]

[Mike Morrin <morrinmike () gmail com>]

Sylvain Munaut wrote:

> > - CSN1 decoding is manually coded right now - and wrong in some places.
>
>  Automatic creation like ASN.1 possible but rather hard problem.

> Something pretty important to me is that the code can be modified to
> "look" nice.

> For eg. when you look at the TETRA dissectors that uses ASN.1
> autogenerated stuff the field values are presented but the names are
> obscure and most of the time you have no idea what they mean unless you
> have the spec opened at the right page beside you.

> While on the other hand when you look at the output of the manually
> crafted CSN1 (well, it uses a CSN1 helpers of course) code of GMR1, each
> value is nicely presented, with field meaning from the specs if appropriate
> and the value properly decoded (like if an integer represents a frequency
> in 0.5 Hz increment, it will display that).

> So IMHO the approach currently used right now (a csn1 generic framework +
> description of the structures in specific files) is not bad, it just misses
> something to "pre generate" all the boilerplate stuff from a .csn1 file.

Note that there are currently two forms of csn.1 dissection in wireshark.
*  The handcrafted, in-line dissection stuff, such as packet-gsm_a_rr.c
*  The table driven, engine-dissected stuff using packet-csn1.c as a
dissection engine, such as packet-gsm_rlcmac.c.

I  recently gave  the csn.1 dissection in packet-gsm_a_rr.c a significant
facelift, and although the source code is a bit fiddly, I does format the
dissection in a highly readable manner.

I am currently embarked on some significant enhancements to
packet-gsm_rlcmac.c, including dissection of RLC data headers and
improvements to readability of the dissection.
With practice the table driven dissectors are quicker to write, but they
can be rather obscure on first acquaintance, especially for nested
structures and loops.

Anyway my main point is that csn.1 is generally an evolutionary dead-end,
and other than minor extensions in the 2 GSM protocols that use it, it is
unlikely to be used in new protocols (for commercial and IPR reasons), so I
would not recommend people to lose too much sleep trying to auto-generate
csn.1 dissectors.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe