Comment # 12
on bug 8579
from Evan Huus
Thanks for your work - the source is much larger, but do note that most of that
isn't executable code, it's tables of data describing the fields in the
protocol. I really am much more comfortable with this version :)
I have given this a fairly thorough testing and I have come across only one
possible issue: there are certain packets in the sample capture (#818 and
others) that produce an assertion if you force them to decode as Asterix:
Warn Dissector bug, protocol ASTERIX, in packet 818: proto.c:2826: failed
assertion "hfinfo->type == FT_FLOAT"
I've dug a little, and it looks like there are some fields that are listed as
either FIELD_PART_FLOAT or FIELD_PART_UFLOAT in your tables but are being
registered with Wireshark as some other type of field (mostly FT_UINT8).
I ran a quick shell script to look for occurrences of this and found the
following hf variables:
&hf_062_270_LENGTH,
&hf_062_270_ORIENTATION,
&hf_062_270_WIDTH,
&hf_062_290_01_TRK,
&hf_062_290_02_PSR,
&hf_062_290_03_SSR,
&hf_062_290_04_MDS,
&hf_062_290_05_ADS,
&hf_062_290_06_ES,
&hf_062_290_07_VDL,
&hf_062_290_08_UAT,
&hf_062_290_09_LOP,
&hf_062_290_10_MLT,
&hf_062_380_04_IM,
&hf_002_090_RE,
&hf_002_090_AE,
&hf_034_090_RE,
&hf_034_090_AE,
&hf_062_110_06_TOS,
&hf_062_210_AX,
&hf_062_210_AY,
Should these simply be registered as FT_FLOAT or is there something more
complicated at work?
Thanks,
Evan
You are receiving this mail because:
- You are watching all bug changes.
