issues with public address type when applying scan filter

[ajkahl]

I'm trying to connect to a device with a public address using an address filter in the scan (not whitelisting), I've seen plenty of similar unresolved issues posted here. So this is my take;

nrf_ble_scan_filter_set(&m_scan, SCAN_ADDR_FILTER, m_target_periph_addr.addr);

eventually gets to:

// Decode address type.
addr_type = nrf_ble_scan_address_type_decode(temp_addr);

which attempts to decode the type from the given address itself, from what I can tell this will only work with non-public (or random) addresses, my reading of the bluetooth spec may be wrong, however...

also states:

// See Bluetooth Core Specification Vol 6, Part B, section 1.3.

yet, again from what I can tell it does not follow this:

I can force the address type in the code above and have success, otherwise it decodes incorrectly, and given the match needs to occur on both address and type it fails.

So I guess my question is has anyone (SDK16 or other) successfully used an address filter (ie. a single filter or match all with some combo) to scan for a public address? Am I missing something? or is this actually an issue with the lib?

[Edvin]

Hello,

Please note that from the Bluetooth Specification has "Address [47;46]", while the SDK use 46;47, so the bit order is swapped.

 

which attempts to decode the type from the given address itself, from what I can tell this will only work with non-public (or random) addresses

 Why is that?

[ajkahl]

Edvin said:

Please note that from the Bluetooth Specification has "Address [47;46]", while the SDK use 46;47, so the bit order is swapped.

I can't see where those bits are swapped? but in any case the decode function returns the sub-type of a random address type, a public address, according to the spec referenced, is not part of this.

I'm assuming that a public MAC used in this scenario is not limited to having the top 2 bits of it's MSB set to 10 (or in fact restricted to anything that would reliably decode an address type or sub-type). 

[Edvin]

ajkahl said:

I can't see where those bits are swapped?

Sorry. I i mixed it up. It isn't.

 

ajkahl said:

but in any case the decode function returns the sub-type of a random address type, a public address, according to the spec referenced, is not part of this.

 I think that are only different names for the same thing. The two first (or last, depending on what way you look at it), is declaring what type of address it is. 

Please see carles' answer in this ticket.

Are you referring to the public addresses that you purchase through IEEE? How the assigning of these are actually done, I am not sure, but in BLE, you need to us 0b01 for a public address.

[ajkahl]

Thanks Edvin, I'm still not understanding what is happening here and if I'm missing something completely as far as the BT spec goes, but It might help if I run through my specific example and symptoms:

- The peripheral I'm scanning for is a rigado BMD300 with a factory programmed IEEE MAC, in this case the rigado format is 94:54:93:XX:YY:ZZ

- The peripheral address type is set to public

- I can scan for and connect to this using nRF connect without issue, and the mac/address shows as per the above format

- Given the address starts with 9 we know the top two bits are 0b10

- According to the ble spec above this would decode as 'reserved', which, given it should definitely not be any of the others I'm going to make the assumption for now that this might now be used for public addresses

- When debugging the decode function responds with case 2 (naturally) - 'random private resolvable' and hence the scan/connect fails.

Now I feel this is all pretty moot, because as I state above the determination of whether an address is public or not isn't decodable by the top two bits of the address, and hence my issue with the library decode function. According to the spec, and this post  an extra flag bit is used to indicate if an address is public, AFAICT this is set on the advertising device using sd_ble_gap_privacy_set.

So the issue to me seems that nrf_ble_scan_addr_filter_add ignores the explicit address type as it exists in ble_gap_addr_t and instead uses nrf_ble_scan_address_type_decode which inevitably does not return the desired result, because it simply isn't given enough information to do so, namely is the address type public or not.

A simple fix in this case might be to pass the entire ble_gap_addr_t to nrf_ble_scan_addr_filter_add  and use the address type specified there (or at the very least if set to public, do not use the decode function). Additionally then resolving the fact the decode function does not match the spec.

[simone.bonetti]

i'm facing exactly the same issue. My company has a registered IEEE MAC address with the following format: 00:15:42:XX:YY:ZZ and i want to filter a specific device upon scan.

The peripheral device has been setup with the following configuration and i can correctly see the MAC address during advertising (from a phone using nRF Connect)

static ble_gap_addr_t m_dev_address =
{
    .addr_type    = BLE_GAP_ADDR_TYPE_PUBLIC,                                       /**< See @ref BLE_GAP_ADDR_TYPES. */
    .addr         = {0xAA,0xBB,0xCC,0x42,0x15,0x00}                                 /**< 48-bit address, LSB format. */
};

I tried to setup a central device with an address scan filter, but since the 2 MSB of my address is 0b00, it is automatically decoded as "Non-Resolvable Private Address" by the function "nrf_ble_scan_address_type_decode" as ajkahl noted, and the scan filter fails to work.

The function expects the address to be decoded as "Public" if its MSB is 0b01, but this is not compliant with the BT specification, as stated by ajkahl in the first post.

i'm actually struggling to find a workaround for this, because with the current implementation of "the  nrf_ble_scan_address_type_decode" function its impossible to use an address scan filter with the MAC address i'm providing.

Can you please confirm that it's a SDK bug? or else me and ajkahl have some serious issues into understanding BT specifications