Wireshark · Wireshark-dev: Re: [Wireshark-dev] Header field with scaling factor/units?

[Guy Harris <guy@xxxxxxxxxxxx>]

On Apr 9, 2014, at 11:01 AM, "John Dill" <John.Dill@xxxxxxxxxxxxxxxxx> wrote (in a font that gets rendered as rather small characters in my mail reader - you might want to use larger type to help out those of us with aging eyes):

> I have a common use case (hundreds to low thousands of data elements) where I need to take some data, encoded in an integer FT_UINT[8|16|32], sometimes has a bitmask applied, and needs to be multiplied by a scaling factor that may be an integer or floating point value, with an optional units string.  I didn't see a use case in README.developer that directly handles this scenario.

Unfortunately, while both scaling and appending units would be useful for a number of fields, we don't have mechanisms to support them.

> Since at the moment it appears that I need to overwrite the item's text string to accomplish what I want, I was considering hijacking the 'strings' member to store the scaling factor and units strings.  Then I could test for the existence of a scaling factor/units string in the hf->strings member.  I'll probably have to package it into a VALS and use try_val_to_str to access the units string to remain compatible with 'proto_tree_add_item' before I rewrite the text representation.    The scale factor code be encoded as a string where I'd have to convert it on the fly using some form of strto[d|l|ul].  Of course this could be just added inline with the dissector code, but it would be nice to have a place in the hf_register_info declaration that documents this information.
> 
> I would think it would be possible to extend the FT_ types with a constant, that informs the api that the scaling factor and units are encoded in 'hf->strings' as [{ 0, "0.25" } { 1, "pounds" }] with a new interface function or two to implement it.

Currently, the header_field_info structure has a field named "display".  Originally, it was used only for numerical values, to control the base in which to display the number; it's now used for other field types to control how they're displayed as well.  In addition, for numerical fields, there are some flags that can be set to indicate how to interpret the next field...

...which is the "strings" field.

I might be inclined to, for numerical fields, divide the "display" field into a 4-bit field used for the base and another field indicating how the strings field is to be interpreted (currently, that's what we have, but they're implemented as bit flags, which means that there are mixtures of flags that might not make sense).

We could add an additional type, in which the "strings" field encodes a scaling factor and units; perhaps integral and floating-point scaling factors could have different types.  (I would include the scaling factor as a number, not a string.)

I would also rename "strings", while we're at it - I think "display" might have been called "base" in the old days.

> How difficult would it be to allow a filter expression to be able to search on a header field whose condition assumes that the scaling factor has been applied, i.e., the data is an integer and has a scaling factor of .25 and you want to filter its value using a floating point value (probably quite difficult I'm guessing)?

We'd probably want to support both filtering on the raw and displayed value of a field.  We can already do that with "enumerated" fields - if you have a field with a value_string table that maps 2 to "Hello", then you can do

	proto.field == 2

or

	proto.field == "Hello"

We might want to add syntax so that, for a field with a scale factor of 0.5, we might have

	wlan.rate = raw(22)

or

	wlan.rate = 11

(no, that was not a randomly-chosen field example :-)).  Other suggestions for the syntax are welcome.