Hi,
handling for GUID fields has been changed to support both byte ordering.
As it is my 1st such a large change in field handling code
please let me know if I did something wrong :)
It has been tested in H.225 protocol (displaying and filtering)
Regards,
Tomas
Mailcode: V55BCPWP
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Tim Potter
Sent: Friday, March 10, 2006 3:10 AM
To: Ethereal development
Subject: [Ethereal-dev] Byte ordering in guid_to_str_buf()
Hi everyone. I was chasing down why the GUID displayed in a PXE BOOTP
request didn't match the one written on the back of my server. The
answer of course is byte ordering.
Unfortunately The Open Group doesn't specify a byte ordering in their
definition of a GUID[1], but rather leaves it up to whatever protocol
transmitting the guid to sort it out. The guid_to_str_buf() function
doesn't get passed a endianness flag, and in BOOTP it's pretty hard to
figure out what this value should be.
The code for the FT_GUID type assumes that the GUID is stored as a
16-byte blob (and displays the GUID in big-endian format), but the GUID
code in the DCERPC dissectors checks and honour the little-endian flag
in the ndr data representation header.
The following patch displays GUIDs in little-endian but I'm not sure
whether this is the best solution or not.
Aargh - this gets more complicated as I've just noticed the
guid_from_unparsed() function which makes things even more messy.
Anyone have any ideas on where to go from here?
Tim.
[1] http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
