That¹s what I thought as well, but I think we were mistaken I believe the idea was so that tiny devices (like tile) can create an address without having to have manufacturing stuff happen.
It looked to me like both zephyr and soft device want to try to keep these random addresses forever. Paul On 5/13/16, 2:43 PM, "will sanfilippo" <[email protected]> wrote: >Why exactly do you want to store the random, static address? My >understanding is that this is expected to change with rebootsŠ > >> On May 13, 2016, at 1:59 PM, [email protected] wrote: >> >> I'm working on LE privacy modes. I reviewed The soft device from >>nordic and also zephyr and have the following proposal >> >> Privacy API proposal >> >> 1. a config for address mode >> * Identity. >> * NRPA >> * RPA >> 2. A address timeout to rotate NRPA/RPA >> >> Initialization - >> The default mode will be Identity addressing: >> >> * If you are configured for identity address mode, the host code >>will try to get the identity address from the controller. If it gets >>the identity address it will use it >> * If that is unavailable it will checks its NV storage for a static >>private address. If it gets one, it will use it. >> * If that is not found, it will generate a static private address >>and store it in the NVRAM. >> >> If you are configured for NRPA or RPA, they are used for all scans, >>advertising and connections. The host stack will use the controller >>for RPA generation and decoding. >> >> The host will keep a non volatile key-cache for IRK that has a >>configurable size. At boot, these will be loaded into the controller. >>Whenever a new key is retrieved in bonding, it will be added to the NVM >>and to the controller. >> >> Comments please. I don't have a lot of experience here and any advice >>would be appreciated. >> >> One observation. The Zephyr stack seems to always use random addresses >>for active scans. Do we want to do the same? >> >> >> >> >> >> >
