I don’t know exactly how the BD_ADDR works, but you might try generate a hash (maybe SHA256? ) from CPU ID (function cpuid_get ).
Then you can truncate to 48 bits and manually set/fix required bytes. Of course the truncation makes the hash weaker in terms of the chances of having 2 same BD_ADDR, but I think that’s very unlikely.
alternatively, instead of truncating you can just "fold" the remaining
bytes over using XOR this way you keep some of the variance introduced
by the longer hash.
A random BD_ADDR is “okay” for testing, but just be aware of the requirement for an OUI as discussed in BLE Core specification, volume 2, section 1.2 . Also, steer clear of the reserved range mentioned in section 1.2.1.
Thanks to all of you for your help! Generating a hash based on the CPU ID seems like a great solution.
@Brett My understanding of the BLE specs was that a device was allowed to use a random address rather than a public one, thus effectively bypassing the need of an OUI (volume 6, part B, section 1.3). Did I misunderstood?
In any case I should definitely stay clear of the reserved range, thanks for pointing that out!