As of Wireshark 1.4, calls to proto_tree_add_item() should take an ENC_ value or a combination of those values to specify the encoding of the item being fetched from the packet; the last argument is no longer a Boolean specifying only the byte order. For integral, floating-point, and Boolean fields, IPv4 addresses, GUIDs, and "counted byte array" fields (FT_UINT_BYTES), ENC_BIG_ENDIAN should be used rather than FALSE and ENC_LITTLE_ENDIAN should be used rather than TRUE. (For IPv4 addresses, ENC_BIG_ENDIAN is almost always correct, although there's one protocol that sends out little-endian, i.e. byte-swapped from network byte order, IPv4 addresses!) For FT_NONE fields, protocols, MAC and IPv6 addresses, OIDs, and byte sequences (FT_BYTES), ENC_NA ("Not Applicable") should be used. For character strings, for current releases, ENC_NA should be used; for the upcoming 1.8 release, that should be combined with a character encoding such as ENC_ASCII (8-bit bytes with the 8th bit never set, i.e. *only* ASCII), ENC_UTF_8, ENC_UTF_16, ENC_UCS_2, and ENC_EBCDIC.
(A quick look at the PIDL generator seems to indicate that it's using proto_tree_add_item() for "aggregate" values such as structures; an "aggregate" value is probably either FT_NONE or FT_BYTES, in which case it should use ENC_NA. I'm not sure about the bitmaps, but presumably those are *supposed* to be in the sender's byte order, which is not *guaranteed* to be little-endian - when Apple still sold PowerPC machines, its implementation of DCE RPC in the SMB client sent stuff over the wire in big-endian format.)
Created attachment 7560 [details] Patch to use ENC_ values for proto_tree_add_item() calls Here's a patch for this. It appears that the integral value containing the bits in a bitmap should be dissected according to the data representation, as the individual fields are fetched by dissect_ndr_XXX, which is passed the data representation and extracts the value appropriately for the data representation, so the patch replaces TRUE (which meant "always little-endian" when the last argument to proto_tree_add_item() was a byte-order Boolean) with DREP_ENC_INTEGER(drep) (which means "ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN, depending on the data representation"). For structures, I'm just using ENC_NA.
Merged, landed in a66865dd287073f21ce279d52450582ea290c7df Thank you!
Moving PIDL bugs into Samba as we do not release PIDL separately.