This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Are the UUID's generated with nRFgo valid?

Hi,

I just took a look to nRFgo to see how it generates vendor specific UUID's. It looks if they are generated completely random including the version number. According to RFC4122 the UUID string had the format of:

xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx

where V is the version number of the UUID. For random generated UUID this should be 4. If i look to the generated base uuid's in nRFgo than the V part is also random. I think you end up with an invalid UUID or am I wrong?

  • You are correct, the UUID generated does not appear to be a Version 4 UUID. However this does not mean that the number generated is incorrect , it however does not conform to the Version 4 UUID convention. You can edit the number created to match the Version 4 UUID. i.e. using the nRGgo studio as a random number generator.

  • The UUID must comply to ITU-T Rec. X.667 | ISO/IEC 9834-8 (technical equivalent to RFC4122) according to Bluetooth specification. Therefore I think it is incorrect to assume that the UUID generated by nRFgo are correct.

  • I must clarify. The impact of the a fully random 128bit number used as a UUID in the BTLE world is not a major issue simply because it is used only for vendor specific UUIDs and these are usually used in systems where the vendor controls both ends of the link that looks at this UUID. At this point I do not see any part of the BTLE UUID ecosystem that discriminates based on type of UUID, thereby reducing the impact of this issue. Let me know if there is a specific impact that you see. [Edited response to clarify]

  • I can only agree that the change of generating a random 128-bit UUID in BTLE world causing issues is virtually zero. But,... There is a specification. The reason for creating a specification is that we can talk the same language in BTLE world. Nordic complies to the BTLE specification with its softdevice because Nordic used that specification and have been qualified. Why make an exception for generating UUID's? I don't see no reason for not complying to standards.

  • Remember vendor specific UUIDs are generated by the user and not by the softdevice, the nRFgo studio is an optional tool to do so and there are many other ways the user can use to generate UUIDs but this is really in user space. In any case I will request a fix in nRFgo studio.

1 2