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
Index: epan/to_str.c
===================================================================
--- epan/to_str.c (revision 17540)
+++ epan/to_str.c (working copy)
@@ -882,9 +882,9 @@
gchar* guid_to_str_buf(const guint8 *guid, gchar *buf, int buf_len) {
g_snprintf(buf, buf_len, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
- guid[0], guid[1], guid[2], guid[3],
- guid[4], guid[5],
- guid[6], guid[7],
+ guid[3], guid[2], guid[1], guid[0],
+ guid[5], guid[4],
+ guid[7], guid[6],
guid[8], guid[9],
guid[10], guid[11], guid[12], guid[13], guid[14], guid[15]);
return buf;
Attachment:
signature.asc
Description: This is a digitally signed message part
