Well, this is exactly the bug - that it disregards the endianness of it.
On Feb 12, 2008 6:08 PM, Lars Friedrichs <
larsfriedrichs@xxxxxx> wrote:
Hi Kaul,
that is simply network byte order vs. host byte order. on the network
all numbers are transfered big endian style so the most significant
byte is always the last byte. If you look closer you will notice it's
just turned around.
Bye
Lars
Kaul schrieb:
Running 0.99.7, on Windows, capturing Active Directory
LDAP communication, there's some wrong display of GUIDs (object type
objectGUID). For example, what on the wire looks like (hex) 25 ff 7e 7d
1a f2 a2 49... should be 7d7eff25-f21a-49a2-... (I think the rest is
like the wire). However, I see that on the search request, even though
on the wire it is the same, it is printed as 25:ff:7e:7d;1a:f2:....
Am I correct to assume it is because the assertionValue print naively
prints the data, with disregard to its actual content?
In the reply, as the item is indeed dissected as a GUID, it is
displayed properly.
TIA,
Y.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
