Mac Address

UUID is just a 16-byte value. Printing its bytes in the hexdump-like style (as is, without rotating the bytes) is okay. Rotating the bytes is okay too -)

Sure, if you express the UUID in bytes, but what are the RAW bytes?

If you call something an UUID and refer to RFC4122, you must use that definition and byte order

The formal definition of the UUID string representation is
provided by the following ABNF [7]

UUID = time-low "-" time-mid "-"
time-high-and-version "-"
clock-seq-and-reserved
clock-seq-low "-" node

In the absence of explicit application or presentation protocol
specification to the contrary, a UUID is encoded as a 128-bit object,
as follows

The fields are encoded as 16 octets, with the sizes and order of the
fields defined above, and with each field encoded with the Most
Significant Byte first (known as network byte order). Note that the
field names, particularly for multiplexed fields, follow historical
practice.

The result of istat seem like being partially rotated and partially not, also according to this
https://docs.python.org/3.1/library/uuid.html

If the data in the hex bytes is read as "Big Endian" or "Little Endian" (if it was a whole 128 bit field) you would have from RAW
000102030405060708090A0B0C0D0E0F
either of
1) 00010203-0405-0607-0809-0A0B0C0D0E0F
2) 0F0E0D0C-0B0A-0908-0709-050403020100
but it seems like what is output is "mixed", this is what I don't understand
https://docs.python.org/3.1/library/uuid.html
the bytes are an assembly of six fields
time_low the first 32 bits of the UUID <- this is "reversed"
time_mid the next 16 bits of the UUID<- this is "reversed"
time_hi_version the next 16 bits of the UUID <- this is "reversed"
clock_seq_hi_variant the next 8 bits of the UUID <- this is "straight"
clock_seq_low the next 8 bits of the UUID <- this is "straight"
node the last 48 bits of the UUID <- this is partially "reversed" and partially"straight"

I simply don't get it. 😯
Still I believe if these matters are made as clear as possible the risk of misunderstandings/mistakes will be reduced.

jaclaz

I see the following bytes in the hex editor 8F CF A0 A6 80 7D E6 11 A6 99 52 54 00 12 34 56.

I see the following bytes in the hex editor 8F CF A0 A6 80 7D E6 11 A6 99 52 54 00 12 34 56.

OK.
So if they are interpreted as a "whole number" Big Endian they should become
8FCFA0A6-807D-E611-A699-525400123456 <- "wrong"
and if they are interpreted as little endian
56341200-5452-99A6-11E6-7D80A6A0CF8F <- "wrong"

So they must be divided into fields of bytes 4-2-2-2-6
Big Endian
8FCFA0A6-807D-E611-A699-525400123456 <- "wrong" (same as above)
small endian
A6A0CF8F-7D80-11E6-99A6-563412005452 <- "almost right" (valid UUID v1 but the MAC address is different from what stated) 😯

C\>uuid -d A6A0CF8F-7D80-11E6-99A6-563412005452
encode STR a6a0cf8f-7d80-11e6-99a6-563412005452
SIV 221486824624917256024806667754716288082
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-09-18 091658.622145.5 UTC
clock 6566 (usually random)
node 563412005452 (local unicast)

So the last field must seemingly not be inverted (it is then not a number but rather a sequence of bytes?) and we finally obtain the (supposedly) "right" one ?
A6A0CF8F-7D80-11E6-99A6-525400123456


C\>uuid -d A6A0CF8F-7D80-11E6-99A6-525400123456
encode STR a6a0cf8f-7d80-11e6-99a6-525400123456
SIV 221486824624917256024806663493807912022
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-09-18 091658.622145.5 UTC
clock 6566 (usually random)
node 525400123456 (local unicast)

Now what happens in istat?

Object Id 56341200-5452-99a6-11e6-7d80a6a0cf8f

It is the same as interpreting the whole sequence as a single number little endian.

Can you confirm the MAC address?

According to the mentioned python related page all the fields are integers and I believe they should be stored in the same way.

jaclaz

Node ID is an array, so you don't need to rotate the bytes.

node 525400123456 (local unicast)

This is correct.

Node ID is an array, so you don't need to rotate the bytes.

node 525400123456 (local unicast)

This is correct.

Good ) , though this is not at all clear in the documentation I found.

Specifically the mentioned python page call the data six "integers".

I guess I need to do some experiments with that Python uuid thingy.

Still to remain on that Python page, it seems like istat uses *something like* UUID.int instead of *something like* UUID.urn

Maybe it is just me, but it is the usual mess of contrasting, confusing info ( .

"I like standards, there are so many of them" wink

jaclaz