Hi Prasad, I understand that there are controllers without LL Privacy support, but to be honest this feature was added a few years ago and there were already few subsequent Core spec versions adopted in the meantime so I'd rather assume LL Privacy is a standard feature for an LE Controller in 2020 and vote against adding support for host-based privacy in our host.
Moreover, I think you don't really need it. Since NimBLE APIs resemble HCI interface (which is a good and a bad thing, depending on what you need - in this case it's the former) you can handle privacy in your app. I think all required APIs should be available, but let me know if you think something is missing and we can figure out what to do. Such privacy support could be wrapped inside a separate module for app to use rather than being integrated inside NimBLE. Another option to consider is a layer between HCI transport and host (could be just a separate HCI transport with this layer integrated) which will translate HCI traffic from a LL-Privacy-aware host to non-LL-Privacy-enabled controller. This basically means resolving list and address resolution/generation would be performed by this layer and there would be no host changes required. This is obviously quite tricky to do, so I think just handling privacy inside app is a much easier solution here. Best, Andrzej On Thu, Jan 30, 2020 at 6:46 AM Prasad Alatkar <prasad.alat...@espressif.com> wrote: > Hi Andrzej, > > Thank you for your reply. I was thinking of adding "Host based privacy" as > an additional feature, by default "Controller based privacy" will be used. > I thought this feature will be useful for NimBLE Host only implementation > where vendor's controller does not support privacy feature. Please let me > know your take on this. > > Regards, > Prasad > ------------------------------ > *From:* Andrzej Kaczmarek <andrzej.kaczma...@codecoup.pl> > *Sent:* Thursday, January 30, 2020 6:09 PM > *To:* dev@mynewt.apache.org <dev@mynewt.apache.org> > *Cc:* Hrishikesh Dhayagude <hrishikesh.dhayag...@espressif.com> > *Subject:* Re: NimBLE: Host based privacy support > > Hi Prasad, > > On Thu, Jan 30, 2020 at 1:13 PM Prasad Alatkar < > prasad.alat...@espressif.com> > wrote: > > > Hi all, > > > > I have been working on "NimBLE host based privacy (RPA)" with no > > involvement of controller for past few days, spec ref: Vol 3, part C, > > section 10.7.1.2 / 10.7.2.2 (Privacy Feature in a Peripheral/central with > > Host-based privacy). Before I come up with pull request, here are few key > > points: > > > > 1. Similar to `BLE_LL_CFG_FEAT_LL_PRIVACY`, add > > `BLE_HOST_BASED_PRIVACY`. > > 2. As controller is not aware of host based privacy, we can not > > directly use "own address type = BLE_OWN_ADDR_RPA_PUBLIC_DEFAULT". I have > > tried to use "own address type = BLE_OWN_ADDR_RANDOM" for this feature. > > 3. Provide API to enable/disable Host based privacy, wherein the RPA > > will be generated and address will be set in controller as > BLE_ADDR_RANDOM, > > provide API similar to `ble_hs_id_set_rnd` which sets RPA address. > > 4. Handle the peer side privacy in `LE enhanced connection` & > > `advertisement reports`, save the peer RPA in "Peer Records" (similar to > > Resolving list ). > > 5. Once the pairing is done and bond is established, add device to > > resolved list (maintained in host) and update corresponding "Peer > record". > > 6. While reconnecting, check if the peer is RPA, check if it is > > resolvable by any entry from "peer records", get entry from "resolving > > list" corresponding to it and we are done with the reconnection. > > > > > > Please let me know if this is an acceptable approach for mynewt nimble. > > > > NimBLE does not support host based privacy by design - it works primarily > with NimBLE controller (i.e. 4.2+) which does support LL Privacy and thus > simply assumes such support. I think this is just fine and unless you have > a very good reason why host based privacy support is required, we should > keep it as it is now. > > > > > > Regards, > > Prasad > > > > Best, > Andrzej >
