Hi Guy and Chris,
>> Assuming the reporter of bug 5769 is correct and the Info column displays the values of the low and high limits correctly, then the protocol is ENC_BIG_ENDIAN. All of the fields affected by r38106 are either FT_UINT8's or FT_BOOLEAN's spanning 1 byte, so endian-ness really doesn't matter, but if someone does the old "copy-and-paste" thing later on, [s]he might incorrectly copy an ENC_LITTLE_ENDIAN when it should be ENC_BIG_ENDIAN.
I have access to the BACnet standard, and need to update the dissector
to expand some enumerations and value strings soon (the standard keeps
expanding, for some reason). Most likely the conversions are Big
Endian as most encodings in BACnet are network byte order, and most
likely the cause of TRUE in the fields is from copy-paste (I'm sure
I'm guilty of that). I'll review the changes and submit a patch if it
is needed. Is there any other cleanup in the BACnet dissector that
needs attention?
Best Regards,
Steve
--
http://steve.kargs.net/
