RE: using public MAC address

Edvin — Wed, 16 Feb 2022 13:26:30 GMT

Hello,

I am not sure why, but for some reason I thought you were using the nRF Connect SDK, but I see that you are using the nRF5 SDK. What SDK version are you using? I discussed this with a colleague, who informed me that this was a bug in the older SDKs, but it is fixed in SDK17.1.0. If you examine thenrf_ble_scan.c file in SDK17.1.0, you can see that the function you refer to is removed (unfortunately, because it didn't interpret the addresses correctly before, and it wasn't possible to fix this parsing without an API change).

So I suggest that you use SDK17.1.0, set the address type to public, and use your public address as the entire address. The bit that suggests whether an address is public or private is not part of the Bluetooth LE address uin8_t addr[0-5], but actually a bit outside this. Please see this discussion.

[quote user=""]1. isn't this code conflict with the use of IEEE MAC addresses?[/quote]

Yes it does. Fixed in the latest SDK.

[quote user=""]2. if our MAC is "uint8_t mac[6];" then these two bits settings the address type should be bits 6:7 in mac[5] or bits 6:7 in mac[0]?[/quote]

Neither. The public/private domain is not determined by these two bits.

Best regards,

Edvin

RE: using public MAC address

Edvin — Mon, 07 Feb 2022 21:12:55 GMT

Hello,

At first glance, this looks a bit weird, I agree.

I believe it is the bit 6:7 in mac[0], but I have not tested this in Zephyr yet. I am not 100% sure it is the same endianness as it was in the nRF5 SDK. I will check this tomorrow.

Some places I find indications that these bits can be anything (assigned by IEEE), while other places it looks like they need to be 0b01.

I am sorry. I ran out of time today, but I will try to clear this up tomorrow. I have seen this question a couple of times before, but I don't remember what the conclusion was. I will try to dig up some old cases tomorrow.

Best regards,

Edvin