Wireshark Wlua dissection 64-bit flag fields will error on higher bits

[shancock884]

The issue is a spin-off from: #852.

As and when Mavlink uses the high 32-bits of any 64-bit bitfield, the generated Wireshark LUA script will error when it is loaded in Wireshark/TShark. This is due to 2 things:

1/ Creating the protofield bitfield with high bits set:
For bit 32, current code will generate this, which produces an error when starting Wireshark as the value is too big for a 32-bit integer, so it thinks we are setting a bitmask of zero:

ProtoField.bool("mavlink_proto.AUTOPILOT_VERSION_capabilities.HIGH_BIT", "HIGH_BIT", 64, nil, 4294967296)

For values higher than maximum uint32, this should be replaced with this:

ProtoField.bool("mavlink_proto.AUTOPILOT_VERSION_capabilities.HIGH_BIT", "HIGH_BIT", 64, nil, UInt64(0,1))

(it should be noted that this syntax only works from Wireshark v4.2 onwards, released Nov 2023)

2/ Attaching the bitfield value to the tree:
Calling add_le with a uint64 value like this, generates an error (only when a relevant message needs to be decoded).

value = tvbrange:le_uint64()
tree:add_le(f.AUTOPILOT_VERSION_capabilities_flagHIGH_BIT, tvbrange, value)

A fix for now, implemented in #886, replaces value with value:tonumber() for 64-bit bitfields, but this basically chops off any data in the high bits.
This is believed to be an issue with Wireshark itself, which as been raised here: https://gitlab.com/wireshark/wireshark/-/issues/19552

Once fixed, "value:tonumber()" can be replaced back to "value" (or something different, if an alternative way to handle this is proposed by Wireshark developers).

For info: @hamishwillee .

[hamishwillee]

Thanks very much for posting. Let's hope Wireshark fix that issue soon.

[shancock884]

Update: Wireshark have fixed the issue in their master branch, so I suppose it will arrive in a release at some point this year.

They were also able to propose an alternative way to call the tree:add_le function, which works and does not rely on a future version, so I will put forward this as a PR to fix this in due course.
This is to call tree:add_le without the value argument. In this case, Wireshark will directly decode the value using the raw bytes in the tvbrange argument.
Note that we must not remove the value argument for all bitmasks, as there may be cases on COMMAND_LONG messages where the raw value is a float, so this would present the wrong data if Wireshark was left to interpret the bytes directly as a integer.

[hamishwillee]

Thanks for tracking this!