Thanks John,
That does seem to be the pattern, most are caused by:
- a type that later got expanded, and sometimes the older field width and
original subset of values are still used
OR
- a value that is read elsewhere and this is just the field where the value
is added/displayed (not sure in this
The bittorrent one is fine. The message type field in a packet with the
standard protocol is a single byte. There's an Azureus dialect that clients
can switch to if they both speak it, and it has some extra message types
specified with string names only. The dissector uses the message type field
Hi,
I have added another check to CHECK_HF_FILTER in proto.c (extra checks that
only get done in the 'CLANG + Code checks' pipeline build) to check for
values in an item's value_string that could not be represented in the
item's type (e.g. a value of > 255 for FT_UINT8). I can eventually look