Bluez 5.65 mesh-cfgclient failed genrate UUID

Question

I tried to provision a device via Bluez and mesh-cfgclient on my Raspberry Pi.

Bluez: 5.65 Raspberry Pi: 3B+

First I am looking for provisionable devices and get:

Scan result:
    rssi = -38
    UUID = DDDD00000000000000000000000000DD
    OOB = 0000
    URI Hash = 00000000

If I am stating the provision process with:

provision dddd00000000000000000000000000dd

I get the error:

Failed to generate UUID array from dddd00000000000000000000000000dd

If I am trying this:

provision dddd0000-0000-0000-0000-0000000000dd

I get:

Requires UUID

So I don't know which UUID mesh-cfgclient like to get from me. Do someone know what I missed here.

Thanks for your help.

Answer 1

I'm encountering this as well. I don't know if it's a new issue because this is my first foray into BLE mesh...

My findings so far has led me to the UUID needs to comply with RFC-4122.

This is my conclusion based on downloading the bluez source (specifically 5.65), along with the ell source (specifically 0.55) and walking through add_node_setup, which led me to l_util_from_hexstring, which seemed fine.
It was l_uuid_is_valid that doesn't like the format...
It's expecting the variant (==2) and version (between 1 & 5) to be included.
Mind you, when I mention those values, they are the result of bit-shifting, so variant == 0x80, and version between 0x16 and 0x80, and this is all after the UUID we are provided is converted into hexidecimal.

I haven't done it yet, but you can probably use a uuid generator online or in linux (uuidgen).

I will say that at the moment, I don't know why ell is expecting variant to == 2.
Looking at the RFC, section 4.1.1, I'm not seeing any bit combination that equates to 2.
Actually, looking at the wikipedia for it, I see the UUID number 2 doesn't equate to the bit combination, but rather the zero-based position of the list, which is 110 ("Reserved, Microsoft Corporation backward compatiblity").

If we were to alter your dddd00000000000000000000000000dd, I think it might look like dddd00000000 40 00 80 000000000000dd.
I chose 0x40 for version 4, and 0x80 for the variant #2 mentioned earlier (bit-shifted).