Hi Florent, 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 [1]. Also, steer clear of the reserved range mentioned in section 1.2.1.
Kind regards, Brett [1] https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 On Wed, Jun 15, 2016 at 3:27 PM Martine Lenders <[email protected]> wrote: > Hi, > 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. > > Best regards, > Martine > > 2016-06-15 15:12 GMT+02:00 Jose Alamos <[email protected]>: > > Hello, > > > > I don't know exactly how the BD_ADDR works, but you might try generate a > > hash (maybe SHA256? [1]) from CPU ID (function cpuid_get [2]). > > > > 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. > > > > Best regards. > > > > > > [1] http://riot-os.org/api/sha256_8h.html > > [2] > > > http://riot-os.org/api/group__drivers__periph__cpuid.html#ga562e64bc300b062ac82dac98b8af7cf2 > > > > _______________________________________________ > > devel mailing list > > [email protected] > > https://lists.riot-os.org/mailman/listinfo/devel > > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
