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

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 6 on bug 8579 from Marko Hrastovec

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.

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

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

- 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.

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.

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?

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.

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).

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

In my case FieldPart defines the composition of each item. AsterixField defines
which itema are possible and UAP for each category defines what is the
organisation/order of the fields in the message.



There can be more categories in one UDP packet and in each category there are
usually more messages. So we don't need filtering and identifying based on
these items. I don't know how to make display of value in Wireshark that does
not to be identifiable and searchable.

You can see all the categories and thes specifications here:
http://www.eurocontrol.int/services/specifications-documents


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.

---

      You are receiving this mail because:

• You are watching all bug changes.