On Sep 7, 2023, at 9:15 AM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
> I have a question whether I can get the dissected string of the BASE_CUSTOM header field so that I can do analysis on it and convert it to floating point to do range analysis so I can issue an expert info if the value is valid but out of range.
...
> Is there a way for me to peel the dissected result string from "ti" after the proto_tree_add_item call so that I can do validation and range checking for expert info?
Do you want the *dissected result*, or do you want MHz_Frequency and KHz_Frequency or, alternatively, as Frequency, being a sufficiently-large integral type in units of KHz?
"Validation and range checking" sounds as if it might be something such as "is this frequency within the valid range?" (e.g., neither DC nor daylight are in the valid range), which might be easier to do on the frequency as a number rather than by undoing the conversion to a string.
If so, perhaps what's called for is a new mechanism to provide private *encodings*, so that the dissectors registration routine might do something such as
guint32 enc_frequency;
...
enc_frequency = register_integer_encoding_uint64(my_frequency_routine);
where "encode_frequency() would take a tvbuff and an offset (and possibly other arguments as necessary) and provides a 64-bit unsigned integer. Then you could do
ti = proto_tree_add_item(word_tree, hf_XTS_5000_APX_8000_Receive_Frequency, tvb, offset, 6, enc_frequency);
with the registration routine returning an encoding value guaranteed not to collide with any predefined encodings for that type or with any other registered encoding.
On Sep 14, 2023, at 9:52 AM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
> I parse 1553 data
What is "1553"?
IEEE 1553 is "IEEE Standard for Voltage Endurance Testing of Form-Wound Coils and Bars for Hydrogenerators", which is probably not it.
MIL-STD-1553 is a databus, which seems more like the sort of thing for which Wireshark could be involved.
> over ethernet and often times the encodings for certain data items can be... creative. I would certainly prefer to mod a way in Wireshark to use the custom function once for the display and return the dissected display string as part of adding the item to the proto_tree for expert_info validation (an example expert_info is when something demarcated as spare in the expected data is non-zero, indicating some kind of data definition drift to equipment over time).
>
> My use case is kind of an amalgam of proto_tree_add_item_ret_display_string_and_length, but the header field represents a 16-bit up to 64-bit integer that is set to BASE_CUSTOM with a function that returns the resulting dissected string from the custom function pointer.
A custom encoding of the proposed sort, and a custom formatter, could both be used; the custom decoder routine could either itself add an expert info item, or could include both a decoding routine and a checking routine to add expert info.
This could be combined with a custom *display* routine.