issues with public address type when applying scan filter

RE: issues with public address type when applying scan filter

Edvin — Thu, 28 May 2020 10:38:07 GMT

Or take in the entire address, including the type, and set the address type in the filter based on that input. I just tried to point out that it is fixable since this is not part of the softdevice, so you don't have to wait for the next SDK release for the fix.

[quote user="simone.bonetti"]Thanks for the help, hope to see the fix in the next SDK release![/quote]

Me too! Thank you both for reporting.

[quote user="simone.bonetti"]the scan filter NEEDS to evaluate the address type in order to avoid possible "false positives", e.g. 2 devices with the same MAC, but one set as PUBLIC, the other set as RANDOM[/quote]

I don't think this is a real issue.

1: In almost all cases, there wouldn't be two devices with the same address (chances are microscopical).

2: In most cases, the random addresses will not be accepted as valid addresses, because they start with the wrong bits. If they by accident do, then 1) 🙂

BR,

Edvin

RE: issues with public address type when applying scan filter

simone.bonetti — Thu, 28 May 2020 10:28:42 GMT

Yes, that's what is causing the issue, and could be a temporary workaround, but i think that the SDK team should not delete that control when fixing the issue (the scan filter NEEDS to evaluate the address type in order to avoid possible "false positives", e.g. 2 devices with the same MAC, but one set as PUBLIC, the other set as RANDOM), rather, i suggest to evaluate the solution me and ajkahl are proposing.

Thanks for the help, hope to see the fix in the next SDK release!

RE: issues with public address type when applying scan filter

Edvin — Thu, 28 May 2020 08:19:08 GMT

Hello,

The reason that I asked for the example is that it lowers the threshold to actually test it and see the same as you see. It increases the handling speed for tickets.

So, I put together a couple of projects from scratch, and I see what you mean. It reads out the address type from the advertisement, and doesn't deduct it the same way that it is done when you set the address filter.

So I suggest the following workaround:

static bool find_peer_addr(ble_gap_evt_adv_report_t const * const p_adv_report,
                           ble_gap_addr_t const                 * p_addr)
{
    //if (p_addr->addr_type == p_adv_report->peer_addr.addr_type)
    {
        // Compare addresses.
        if (memcmp(p_addr->addr,
                   p_adv_report->peer_addr.addr,
                   sizeof(p_adv_report->peer_addr.addr)) == 0)
        {
            return true;
        }
    }
    return false;
}

Wouldn't that work as a workaround?

As I said, I have reported this to the SDK team.

RE: issues with public address type when applying scan filter

simone.bonetti — Wed, 27 May 2020 14:49:27 GMT

No, i mean that the problem with the nrf_ble_scan_addr_filter_add is that, with the current implementation, it has not enough information to infer if an address is public or random, and it wrongly infer a type just by looking at the first 2 MSB of the user provided MAC.

the user cannot specify the address type in the function parameters, it only accepts a 48-bit MAC address, so it cannot infer if the passed address is meant to be public or random.

for instance, without additional information, the following MAC address 00:15:42:XX:XX:XX could be either"public" or "non-resolvable random private".

That's the reason why the function sd_ble_gap_addr_set (used to set the MAC address of a device, which is then part of the advertising) NEEDS to know both TYPE (whether public or random) and the MAC itself to properly set the TxAdd/RxAdd bits inside the advertising PDU. The nrf_ble_scan_addr_filter_add should work exactly the same, without trying to infer the type when it does not have enough information to do it.

There's no need to provide source codes for a non-working example, just set the following MAC on a peripheral:

static ble_gap_addr_t m_dev_address =
{
    .addr_type = BLE_GAP_ADDR_TYPE_PUBLIC, /**< See @ref BLE_GAP_ADDR_TYPES. */
    .addr = {0xXX,0xXX,0xXX,0xXX,0xXX,0x00} /**< 48-bit address, LSB format. 0xXX could be any number */
};

and then setup a scan filter using the peripheral MAC address on a BLE Central node (you can simply use ble_central\ble_app_uart_c and \ble_peripheral\ble_app_uart as a base example).

You will see that when the filter is applied nrf_ble_scan_addr_filter_add infers that its type is "Non-Resolvable random private" (due to the 0b00) and stores the filter that way.

When a scan is performed, the addresses match, but the type does not (inside filter is "non-resolvable random private" while inside ADV packet is "public") and the connection fails.

RE: issues with public address type when applying scan filter

Edvin — Wed, 27 May 2020 10:48:45 GMT

I have forwarded the report to our SDK team (which doesn't work on DevZone, unfortunately).

Do you mean that nrf_ble_scan_addr_filter_add() changes the address that is added to the filter if it is a public address?

As far as I can tell, it will set an address type (which may be wrong if it is a pulbic address. That I agree on).

Later, when the filter is used, it will be called in on_adv_report() -> if (addr_filter_enabled) -> adv_addr_compare() -> find_peer_addr()

which will check the stored address with the address from the advertising report. Yes, it will also compare the address type, but the (wrongly) assumed address type will be the same as when you added the address.

I may be missing something here, and if so, please let me know. But I don't see why this wouldn't work. If it in fact doesn't run as expected, perhaps you can provide a central and peripheral example where this doesn't work?

BR,

Edvin

RE: issues with public address type when applying scan filter

simone.bonetti — Wed, 27 May 2020 08:57:31 GMT

No, i cannot workaround the issue that way. In the peripheral device, i deliberately set the following address 00:15:42:XX:XX:XX as public, and the addr_type information is correctly encoded the inside the TxAdd/RxAdd bits in the advertising PDU. That's the configuration i'm using:

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 cannot change that configuration because we registered our company MAC address in the IEEE on purpose and it needs to be identified as "public" by all the devices (third party smarphones and such) that can perform a scan as a central role.

The central device i'm developing with a nrf52833 correctly identifies the peripheral device as "public" if i do not add any filter to the scan activity, so the scan report is working correctly.

The current implementation of nrf_ble_scan_addr_filter_add accepts a simple 48-bit address and does not allow me to specify the type to correctly setup the filter, instead it wrongly infers the type based on the first 2 bits (which in my case ends up with a "Non-resolvable private address"), there's no way to workaround the filter.

In my opinion the nrf_ble_scan_addr_filter_add function should work as sd_ble_gap_addr_set. The user shall specify the address AND if the address is just PUBLIC or RANDOM. Then, IF is RANDOM, the function may infer the sub-types (resolvable, non-resolvable) based on the MSB, but if it's PUBLIC, no assumptions on the MSB values should be made.

Another thing that i don't like is that the function nrf_ble_scan_addr_filter_add inverts the passed address to convert it to LSB format. It leads to confusion since it's not clear to the caller which format is expected. Using ble_gap_addr_t as input parameter (which is clearly stated to use LSB format), and getting rid of the inversion inside the function, would solve this as well.

That's basically the same that ajkahl suggested previously as a fix.

Is there a more official way to open a ticket to the SDK devs or will you handle the submission yourself?

Thanks for the support!

RE: issues with public address type when applying scan filter

ajkahl — Tue, 26 May 2020 03:01:34 GMT

Ignore the above, I had max/min connection interval params mucked up. Works now, Cheers!

RE: issues with public address type when applying scan filter

ajkahl — Tue, 26 May 2020 02:28:50 GMT

Hi Simone, I can't seem to get sd_ble_gap_connect to work, it returns NRF_ERROR_INVALID_PARAM, which is:

// * @retval ::NRF_ERROR_INVALID_PARAM Invalid parameter(s) supplied.
// * - Invalid parameter(s) in p_scan_params or p_conn_params.
// * - Use of whitelist requested but whitelist has not been set, see @ref sd_ble_gap_whitelist_set.
// * - Peer address was not present in the device identity list, see @ref sd_ble_gap_device_identities_set.

I'm looking at the last item above and wondering what that's about. Are your m_scan.scan_params & m_scan.conn_params just set to defaults?

RE: issues with public address type when applying scan filter

Edvin — Mon, 25 May 2020 09:32:29 GMT

It seems you are correct. I don't know why I thought that the public addresses needed to start with 0b01 (probably because of the SDK).

Is there a problem saying that the address is the format that you need to use in order to add it to the filter? Non-resolvable private address in the 0b00 case?

RE: issues with public address type when applying scan filter

ajkahl — Mon, 25 May 2020 09:18:52 GMT

thanks for the info, glad you've found a solution. I'll definitely play around with alternatives to the scan/connect.

RE: issues with public address type when applying scan filter

simone.bonetti — Mon, 25 May 2020 08:49:45 GMT

I managed to find a workaround to the issue with the following code:

static ble_gap_addr_t companion_gap_addr;

bool ble_app_start_comm_test(uint8_t * server_addr)
{
    ret_code_t err_code;

    nrf_ble_scan_copy_addr_to_sd_gap_addr(&companion_gap_addr,server_addr);
    
    //overriding due to a possibile issue inside stack inside function "nrf_ble_scan_address_type_decode"
    companion_gap_addr.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC; 


    err_code = sd_ble_gap_connect(&companion_gap_addr,&m_scan.scan_params,&m_scan.conn_params,APP_BLE_CONN_CFG_TAG);
    APP_ERROR_CHECK(err_code);

    return true;
}

basically, in my application, a host device sends via UART the known MAC adddress of the device it wants to connect to in the following format ( 00:15:42:XX:XX:XX ).

i internally convert it to the LSB format required by the SDK and i override the (wrong?) decoded address type to a PUBLIC one.

Instead of scanning with an address filter, i issue a direct connect command with the given MAC address. It works.

Maybe it can help you with your application.

RE: issues with public address type when applying scan filter

ajkahl — Mon, 25 May 2020 08:28:23 GMT

I concur with Simone,

I cannot find any reference to any restriction on the top bits of an IEEE MAC used as a BD_ADDR.

I cannot find any evidence to support the claim "according to the BLE specification the MSB should be 0b01". Please provide it if it exists.

The only limitations imposed on the usage of an IEEE MAC is the block of 64 LAPs used for inquiry operations.

The difference between a public and random address is solely indicated by txAddr/rxAddr bit (a 49th bit if you will).

RE: issues with public address type when applying scan filter

simone.bonetti — Mon, 25 May 2020 07:55:52 GMT

Thanks for the reply! are you sure about the following statement?

"If the device has a public address, then according to the BLE specification the MSB should be 0b01"

I cannot find any evidence of it inside the BLE Core Specifications i'm referencing:

BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B, Chapter 1.3

I also found the following post:

https://devzone.nordicsemi.com/f/nordic-q-a/27012/how-to-distinguish-between-random-and-public-gap-addresses

in which endnode showed some screenshots from the BLE training course in which it's stated that a PUBLIC address cannot be distinguished from a RANDOM one just by looking at the 48-bit address, since it's the TxAdd/RxAdd bit that serves the purpose.

As my understanding, the 24-bit Company IDs (which are assigned by the IEEE) have no restrictions on the bytes value, and in my specific case my company has a IEEE assigned MAC address equal to 00:15:42. (if you put 00:15:42 here https://macvendors.com/ you can see that it matches with MICROHARD S.R.L. which is the company i'm working for).

All the devices we're producing have the following MAC address format: 00:15:42:XX:YY:ZZ and since we're planning to use a Nordic device for the next products we're facing issues scanning with the current SDK implementation of the address filtering.

RE: issues with public address type when applying scan filter

Edvin — Mon, 25 May 2020 07:23:16 GMT

Do any of you have a sniffer trace of the advertising device? Is it a device that you have made yourself, or 3rd party devices? If the device has a public address, then according to the BLE specification the MSB should be 0b01, so in my opinion, it is not an SDK bug. I believe this rule overrules the public MAC address for the advertising device.

If it is a 3rd party device, are you sure the address is in fact starting with 0b00?

If you have created the advertising device yourselves, then I believe you need to look into whether or not you are allowed to use that address or not before going to certification with Bluetooth SIG.

As for the scan address type function, you should be able to just change it, but that will possibly only delay your issues until certification, if the advertising device is not using a valid BLE address.

RE: issues with public address type when applying scan filter

simone.bonetti — Fri, 22 May 2020 10:03:53 GMT

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 😆

RE: issues with public address type when applying scan filter

ajkahl — Thu, 21 May 2020 02:33:04 GMT

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.

RE: issues with public address type when applying scan filter

Edvin — Wed, 20 May 2020 11:49:18 GMT

[quote user="ajkahl"]I can't see where those bits are swapped?[/quote]

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

[quote user="ajkahl"]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.[/quote]

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.

RE: issues with public address type when applying scan filter

ajkahl — Wed, 20 May 2020 02:00:24 GMT

[quote userid="26071" url="~/f/nordic-q-a/61512/issues-with-public-address-type-when-applying-scan-filter/250731"]Please note that from the Bluetooth Specification has "Address [47;46]", while the SDK use 46;47, so the bit order is swapped.[/quote]

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).

RE: issues with public address type when applying scan filter

Edvin — Tue, 19 May 2020 12:58:21 GMT

Hello,

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

[quote user=""]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[/quote]

Why is that?