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/ ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
