Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 8579] Dissector for ASTERIX packets

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 8 on bug 8579 from Evan Huus

Hi Marko, thanks for your detailed explanation. The protocol is certainly more
complicated than I thought it was, but I think we can still manage most of it
with Wireshark's built-in API.

(In reply to comment #6)
> Hi Evan,
> 
> your comments make sense and I was considering using hf array for each field
> but I decided not to because of the following reasons:
> 
> - There are many ASTERIX categories and all have fields named 010, 020, etc.
> That would mean enormous number oh hf variables. The code to use these
> variables could not be general for all categories any more and would require
> large "if else" or "switch" blocks to actually use all these hf's. If I
> declare a variable and then don't use it in the code I get an error since
> compiler is configured to treat warnings as errors in dissectors.

Massive switch statements are fairly common in Wireshark dissectors; it's just
the nature of the problem. Also, massive protocols do generate a massive number
of hf entries most of the time. The more kinds of information the protocol
encodes the more information Wireshark has to have to decode them.

Regarding unused variables, I'm not sure what you mean: the compiler shouldn't
warn as long as it's used in just one case of a switch statement?

Often when switching on types with a lot of fields depending on the switch,
each choice is put into its own function so you end up with code like:

switch (type_value) {
   case 1: dissect_proto_case_1(); break;
   case 2: dissect_proto_case_2(); break;
   default: break;
};

> I guess I could change the code this way but it would be long and harder to
> manage.

It would definitely be longer, but Wireshark would be able to do a lot more
with the data. I don't know that it would much more complicated beyond sheer
length though.

> - Yes, I am reusing hf variables because the same name of item can mean
> something completely different in another category.

It's quite possible to have two totally different items with the same display
name (as long as they have different field names and hf variables).

> - The types which are provided by Wireshark are not quite enough for ASTERIX
> and I don't know how to do it. For instance take a look at the document for
> category 048
> (http://www.eurocontrol.int/sites/default/files/content/documents/nm/asterix/
> cat048-asterix-tmtr-part4-v1.21-20120701.pdf). Lets just take a look at some
> examples:
> 
> a) Item 048/020 is a type of bit field. First three bytes are one value,
> then there are some 1bit values. There are many combinations of signed,
> unsigned values and no rules how many bits some value may occupy. I can't
> use FT_INT, FT_UINT in this case because there are only 8, 16, 24, 32 and 64
> bits possible. In another category 020 item is completely different.

Focusing briefly on just this category for the moment, it looks to me like this
is easily doable by specifying "TYP" as an FT_UINT8 with the appropriate
bitmask of 0xE0 and a value_string. All the single-bit fields can be specified
as FT_BOOLEANs with the correct bit masked and true_false strings attached.

For dealing with the possible extended bytes you don't try and do it all at
once, you would do it in a loop. First decode the single header byte you know
exists, then check the FX bit, and if it's 1 then decode an extent byte and
repeat. None of the actual fields vary in length; the only thing that varies
(according to my reading at least) is how many extents there are, which can be
determined dynamically at run-time.

This data item in other categories would be handled by entirely different code
and hf items, since it's entirely different data to dissect, it just (if I
understand correctly) happens to share the same ID of 20 within the category.

> b) Items don't have LSB bit set to 1. For instance Item I048/040 has two
> values 16bits long. The first value represents the range in nautical miles
> and the second one azimuth angle. However these are not integers although
> represented as integers. The LSB bit for range is 1/256 nautical mile. If we
> print out the value directly as Wirteshark would do, the value would be 256
> times to big. Value 1 is actualy 1/256 nautical mile. The same applies for
> azimuth angle only the scaling factor is different. Practically all values
> which measure something are like these.

(To be sure I understand, this is fixed-point encoding, so the LSB is 1/256 of
a NM, the next bit is 1/128 of a NM, the next 1/64 etc?)

In this case you could create an hf entry for a floating-point number, retrieve
the value from the TVB and perform the appropriate conversion, then use
proto_tree_add_float, passing in the converted value. Honestly wireshark's
fixed-point handling isn't great so I understand that this one's fairly
painful.

> c) Item I048/050 for instance represents the aircrafts code which is 4 octal
> digits. 12bits are used to store these digits. There are some other bits
> also there as flags. How can I show seven digits stored in two bytes?

The hf fields would be defined with bitmasks to select the appropriate bits.
The four octal digits I think can just be displayed by setting the hf to have
BASE_OCT instead of BASE_DEC or BASE_HEX?

> d) Item I048/090 uses 14 bits in two's complement to encode flight level and
> LSB bit is 1/4FL. Again a value that can not be declared with standard
> Wireshark type.

More fixed-point encoding mixed with bit-masking. I think I've covered both of
these points already.

> e) Item I048/240 uses 6 bytes to encode 8 characters for aircraft
> identification (callsign). 6 bits are used to encode one character and 8
> characrets fit in 6 bytes (see AISCode in the source).

In this case you would have to do something similar to the fixed/floating-point
case. Define an hf variable for an ASCII string, do the conversion in the
dissector then add it with proto_tree_add_string. If this format is common you
could turn it into a helper function.

> There are far more fields that can not be decoded and presented with
> standard Wireshark types than the ones that can.

I think Wireshark's engine is more flexible than you realized, though I do
admit the fixed-point fields aren't handled nicely at the moment (I don't know
of any other protocol that uses them so extensively).

> I hope I have answered your doubts satisfactory. I would be happy to answer
> more of your questions to clarify the code and come to the solution that
> would be good for all.

This is an extraordinarily complex protocol, I do admit. I suggest you try
implementing just a small subset (maybe one or two pieces of category 48) in a
new dissector using the normal hf method and see if it's workable. I suspect
you'll find it easier than you thought once you're using the right APIs.

Hope this helps,
Evan

---

      You are receiving this mail because:

• You are watching all bug changes.