>Message: 5
>Date: Wed, 9 Apr 2014 20:17:51 +0200
>From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] Header field with scaling factor/units?
>Message-ID:
> <CAGka-82kZagNG1doy3EmTEyvDRvsCBcijWbparzpcjcCuQwxzQ@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="iso-8859-1"
[snip]
>Hi John,
>
>This is the kind of use case where I personally use BASE_CUSTOM (see
>explained in doc/README.dissector for details).
Pascal,
I did a quick grep of BASE_CUSTOM and it appears that the amount of use is not very large in the current 'dissectors' folder. If there were a small number of fields, that would probably be my choice as well.
The problem is that the scheme in my opinion doesn't scale well. As the number of BASE_CUSTOM elements grows, the amount of maintenance to keep each and every field's separate display routine in sync becomes problematic (particularly for internal test and source code review). Each function has custom code to read the integer from the buffer, apply some bitmask, apply a scale factor, and display the string with any attached units. That means that the components that go into maintaining a header field need to look at its entry in the hf_register_info array, the subdissector function that processes the application-layer message, and now a separate display function for each header field, where there can be dozens of these scaling factor fields per message.
I see enough similarity that a structured method of encoding this mechanism should be feasible. In my project, I've created an XML database of each data element/header field by message. I've structured it in such a way that my group can translate an XML tag (based on the nomenclature used in the documentation) into a header_field entry for Wireshark for many of the basic field types. If I can inject the architecture needed to handle integers with scaling factors into Wireshark using a method through the header_field, I believe that I can reduce the complexity of code generation of the protocol dissector (at the cost of increasing the complexity to adapt the Wireshark application for this use case).
I have no intention of trying to push any change of this magnitude on to mainline Wireshark source tree, but it's a common enough use case that it's worth it for me to try to investigate possible methods to develop it and possibly integrate it into the Wireshark protocol dissection api.
I would actually use BASE_CUSTOM for those fields that need to be assembled from separate words where each component has it's own bitmask. For example, radio frequencies are often encoded as digits, but each of the digits may use 1-4 bits, and there may be implicit offsets and different scaling factors for each component in the data in the calculation itself, like adding an implicit 100 MHz to the frequency (as there is no 100 MHz digit to begin with).
Best regards,
John Dill
>Regards,
>Pascal.
<<winmail.dat>>
