Open AlexanderAmelkin opened 10 years ago
Original comment by: Zdenek Styblik
Hello,
the following statement isn't true:
In IPMI Spec table 20-10, GUID bytes are transmitted in ‘network order’ (most-significant byte first)
Please, see page 278 in PDF(page 252 in printed out version). It says and even shows that the least significant byte is first and the most one is last.
Z.
Original comment by: Zdenek Styblik
Original comment by: Zdenek Styblik
Reported by: Roger Hung Original Ticket: ipmitool/bugs/288
In IPMI Spec table 20-10, GUID bytes are transmitted in ‘network order’ (most-significant byte first) starting with the time low field. But ipmitool display method doesn't match this table format. Also ipmitool uses int32 and int16 to define timestamp (time_low,time_mid,time_hi_and_version) impacted by little endian.
In ipmi_mc.c:519 (ipmitool-1.8.13): / Kipp - changed order of last field (node) to follow specification / printf("System GUID : %08x-%04x-%04x-%04x-%02x%02x%02x%02x%02x%02x\n", guid.time_low, guid.time_mid, guid.time_hi_and_version, guid.clock_seq_hi_variant << 8 | guid.clock_seq_low, guid.node[0], guid.node[1], guid.node[2], guid.node[3], guid.node[4], guid.node[5]);