Dell serial number to UUID transform

This week’s useless exercise is about transforming between Dell serial numbers and UUIDs (in network byte order). Here’s an example showing how it works. The vv indicates direct ascii en/decoding and xx are unused constants. Those constants might mean something, but I have no idea what.

44 45 4c 4c - 33 00 - 10 34 - 80 36 - c4 c0 4f 32 33 4a
 D  E  L  L   vv xx - xx vv   xx vv   || xx xx vv vv vv
            +---<---- AND 0x7f ---<---++
            +--->----  OR 0x80 --->---++
            D  3          4       6             2  3  J

Doing the en/decoding in Python:

import binascii

def decodeuuid(uuid):
    data = binascii.unhexlify(uuid.replace('-',''))
    assert len(data) == 16
    return ''.join([
        chr(ord(data[10]) & 0x7f),

def encodeserial(serial):
    assert len(serial) == 7
    return binascii.hexlify('DELL%c%c%c%c%c%c%c%c%c%c%c%c' % (
        ord(serial[0]) | 0x80,

I originally wanted to fix a blank serial number on a system. It has UUID 44454c4c-0000-1020-8020-80c04f202020, and I thought I could derive the serial from that. Of course it turns out that the serial was just spaces after decoding. This indicates that the UUID is generated from the serial number and not the other way around.


Pulling warranty details from

Update 2014-04-04: In a moment of brilliance, Dell has published documentation for both their warranty and case management APIs! Mind blown. Thanks, Dell. Thell.

In 2012 Brian Mulloy helped Dell launch As opposed to their older SOAP API for warranty lookup, this one actually gives you the full warranty details. Let’s get straight to it.

For any URL access, you need to supply a 16-character apikey URL parameter. Until there’s some sort of registration service available, valid API keys at the moment are:


The URL resources (the last part of the URL path) can generally be accessed three ways:

resource       Returns XML
resource.xml   Returns XML
resource.json  Returns JSON (poorly disguised XML)

There are two interesting URLs. First, the warranty lookup:<args>

Apart from the apikey, you must supply a svctags parameter consisting of a list of 1 to 100 (max) service tags, separated by | (pipe symbol). Here’s an example.

The second interesting URL provides a mapping of codes to descriptions:<ctype>


ctype=type1    Country code to country name or region
ctype=type2    Warranty type code to description

Note that type2 descriptions are already present in the warranty info, so it’s not really necessary to fetch it. Plus, some warranty codes are not listed in the type2 list anyway (for example BZ for “Bronze Software Support”).

Dell have clearly thought of more uses for their api, such as case reporting. While it would be interesting to figure out how it works, it’ll have to wait for now.

I think this api is a very nice step in the right direction, although I wish Dell would open up more to free and independent use (especially of read-only operations such as warranty lookup) instead of the fairly closed approach they’ve taken so far: There’s nearly nearly zero published information about past and current apis — only sporadic forum posts and the occational WDSL — and lots of focus on pushing their management software as the sole consumer of the api. And let’s be honest, Dell does hardware a billion times better than they do software, which is why I prefer the option of handling the software on my own.

HP iLO authorization? Nah

This is old news and certainly not the end of the world, but just so it’s clear: Always keep your management network internal only.

Any version of iLO will by default happily provide anyone who can access it with details on product type, serial number, iLO firmware version, etc. This can be a convenience when autodetecting nodes on your management network.

Here are some exposed iLOs, courtesy of Shodan:

There’s also /xmldata?item=CpqKey that’s probably useful for something.

Oh, and FORTRAN called and congratulated on the all-caps XML.

Fuckin’ UUIDs, how do they work?

Pretty much any computer these days has an smbios full of lovely data. The system UUID is particularly useful for identifying and keeping track of your servers. You happily assume it’s set in stone from now until the end of time, but then someone comes along and fucks up the byte order.

Here are some brilliant wtfs from a HP server:

# dmidecode -s system-uuid

$ curl -ks "https://ilo4/xmldata?item=All"

So the first three fields are in reverse byte order. Which one is the right one? Neither. Or both? Hngh!

HP’s UUID is a simple ascii encoding of the six-digit product number plus the ten-digit serial number:

$ python -c "import binascii as b
print b.hexlify('C1T43A2UX237109F');"

So dmidecode gets it right? Yeeaano. Not according to section 7.2.1 in version 2.6 of the smbios spec. In short, assumptions and poor specs have resulted in yet another mess. Dmidecode 2.10 adds the little endian parsing for smbios versions >= 2.6.

Here’s Dell doing the same thing:

# dmidecode -s system-uuid

Note the broken UUID format in the second field in the iDRAC’s SMASH CLP:

-> show admin1/system1

..and enumerating the WSMan CIM_ComputerSystem class gives the same result:


Dell have later added the WSMan DCIM_SystemView:smbiosGUID value that presents the uuid in network byte order (same as dmidecode <= 2.9).

Oh, and Dell’s C6100 servers come with the same UUID and serial numbers for all nodes in the enclosure. Thanks a lot, Dell.

More details on this UUID wtfery here.