This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Adverting address (id) changes after rebooting

Hi

I am using Zephyr samples (common with the samples found in NCS) to evaluate the advertisement function of nRF52833DK.

I have run these examples:

In both cases, the device's id changes after the reboot (checked by nRF Connect):

Also I tried to change the id before enabling the BLE as described in this devzone ticket, but it didn't work.

Now my questions are:

1- Why after reboot a random address is assigned to the device and it doesn't use the address was assigned to the device at manufacturing time?

2- How can I change the address that is used for advertising?

Regards,

Saleh

Parents
  • Hi,

    Random addresses is a privacy feature. Always using a fixed address is usually a bad idea, as that makes the device easily trackable by anyone with access to Bluetooth LE scanners.

    That being said, the random address policy can be disabled through the "LE Controller-based Privacy" config option (BT_CTLR_PRIVACY), which is the feature that turns on random addresses in all roles. The purpose of this feature is to protect against tracking, and is enabled by default in the examples.

    For devices that connect to other devices, you can enable the "Privacy Feature" config option (BT_PRIVACY), which enables use of Resolvable Private Addresses (RPA) that are being recognized by bonded devices only (that is, devices with the Identity Resolving Key (IRK))

    Regarding setting the Bluetooth MAC address manually, please have a look at BLE MAC address.

    Regards,
    Terje

  • Thanks Terje for your description, especially about IRK procedure.

    Yes, this "BT_CTLR_PRIVACY" is designed to enable privacy feature, which generates random addresses as you have described.

    But even by explicitly disabling this feature (adding BT_CTLR_PRIVACY=n to prj.conf file), it doesn't change the above behavior. Rebooting the system will change the advertiser address again.

    I found to use a constant address, it is needed to pass "BT_LE_ADV_OPT_USE_IDENTITY" as an option to the "bt_le_ext_adv_create" function, then despite of the BT_CTLR_PRIVACY value, the address will be constant after rebooting. for example I changed the "periodic_adv" sample to generate a constant address on each advertising by below modification:

    /* for example in "periodic_adv" sample, these lines should be changed to this */
    ...
    	err = bt_le_ext_adv_create(BT_LE_EXT_ADV_NCONN_IDENTITY, NULL, &adv);
    	if (err) {
    		printk("Failed to create advertising set (err %d)\n", err);
    		return;
    	}
    ...

    Also changing the BLE MAC address as you have referred to another ticket, is only effective when the above option has been used, else it will be overwritten by a random address when "bt_le_ext_adv_start" has been called:

    int bt_le_ext_adv_start(struct bt_le_ext_adv *adv,
    			struct bt_le_ext_adv_start_param *param)
    {
        ...
    	if (atomic_test_bit(adv->flags, BT_ADV_CONNECTABLE)) {
    		if (IS_ENABLED(CONFIG_BT_PRIVACY) &&
    		    !atomic_test_bit(adv->flags, BT_ADV_USE_IDENTITY)) {
    			bt_id_set_adv_private_addr(adv);
    		}
    	} else {
    		if (!atomic_test_bit(adv->flags, BT_ADV_USE_IDENTITY)) {
    			bt_id_set_adv_private_addr(adv);
    		}
    	}
    	...
    }

    Now, my problem is changing the address after when Bluetooth is enabled. "bt_id_create" function only works when is called before "bt_enable" function. How can I change the address after when BLE has been enabled? I tried to use "bt_id_reset" function after stopping the advertisement, but it didn't work.

  • Hi,

    There is bt_set_id_addr(), but it is deprecated (will be removed in Zephyr 2.7) and as with bt_id_create() it cannot be used when Bluetooth is enabled. It looks like the only way is to set the address first, before Bluetooth is enabled.

    A workaround might be to reset the device when a change of address is needed, but the best solution would be if you can design around it so that you do not have to change address. What is the purpose of the address change? There are probably other mechanisms in BLE that achieves the same effect, for instance use of whitelist if you want to control what central should connect, what scanner should get scan response, etc.

    Regards,
    Terje

  • I am developing a "direction finding" solution based on AoA locators and AoA tags.

    Advertising address of AoA tags has been used as an ID to recognize the tags between others (so  by considering as a fixed number, we can follow it over the time, which is a common application of location services).

    Now I want to give the user, opportunity of changing device's id (equals to advertising address), so he/she can change the id (advertising address) at any time.

    The reason that I have used advertising id to follow the tags, is easy access to the "advertising id" in callback function of "CTE received event" (other relevant values should be obtained from other callbacks and then be matched with CTE signal again based on advertising id)

    So do you have any better suggestion to use another parameter instead of a fixed advertising address to recognize the tag?

Reply
  • I am developing a "direction finding" solution based on AoA locators and AoA tags.

    Advertising address of AoA tags has been used as an ID to recognize the tags between others (so  by considering as a fixed number, we can follow it over the time, which is a common application of location services).

    Now I want to give the user, opportunity of changing device's id (equals to advertising address), so he/she can change the id (advertising address) at any time.

    The reason that I have used advertising id to follow the tags, is easy access to the "advertising id" in callback function of "CTE received event" (other relevant values should be obtained from other callbacks and then be matched with CTE signal again based on advertising id)

    So do you have any better suggestion to use another parameter instead of a fixed advertising address to recognize the tag?

Children
  • Hi,

    That would be to either embrace the use of resolvable random addresses, or if you have space in your advertisements to use manufacturer specific data.

    The former requires distribution of Identity Resolving Keys (normally done as part of bonding procedure), but that sounds unreasonably complex for your use case.

    The latter voids the privacy given by using random addresses in the first place. Is privacy (measures against tracking by third parties) a concern for your use case? If so, and going for this option, at least you should trigger address change at the same time as changing id in manufacturer specific data.

    Apart from that, changing the identity address does look like the obvious choice and I will ask internally if there is any way to achieve that.

    Regards,
    Terje

  • Hi,

    Actually, changing a static device address is not allowed by the Bluetooth specification, without a power cycle of the device:

    Bluetooth core specification v5.2, Volume 6, Part B, section 1.3.2.1 Static device address:

    "A device may choose to initialize its static address to a new value after each
    power cycle. A device shall not change its static address value once initialized
    until the device is power cycled."

    So the way to change static device addresses, is to do a reset. You then can initialize with a new address before enabling BLE. By using a random source for setting this address, you should be able to achieve what you want by letting the "reset address functionality" reset the device.

    Finally, to allow resets both to change and not to change the current address, you could write the address to flash (for reuse), and use either GPREGRET registers or write to flash to signal that the address should get updated on next boot.

    Regards,
    Terje

Related