RE: Incorrect CCCD configured by nRF Mesh App on Android

Srikkanth — Wed, 22 Aug 2018 14:41:28 GMT

I do agree that this is not a blocker and also to the fact that it is a spec violation if both services are exposed.
I'm just trying to analyze from an IoP point of view about devices that do expose both the services. One example as suggested above is the PTS tool itself(again, I do agree that there is a greater possibility of PTS correcting it in later version).
What I'm trying to suggest is that if there can be a different mechanism to arrive at the assignment of "isProvisioningComplete" as "True" in the isRequiredServiceSupported(...) routine? Something like maintaining the UUID of the unprovisioned device and checking if its already provisioned etc.
Not sure if maintaining device BLE address would work as there could be devices which are using RPA but not support SMP/Bonding to share the IRKs!

Again, its not a blocker its pondering the possibility of an attempt to be lenient on non compliant[with respect to GATT services] devices!! Especially because BLE spec's ATT or GATT does not impose rules of dynamic exposure/visibility of services :)

RE: Incorrect CCCD configured by nRF Mesh App on Android

Roshan Rajaratnam — Tue, 14 Aug 2018 06:57:02 GMT

Hi Srikkanth this is the intended behavior from the app's point of view. What you are mentioning is not a blocker but a requirement of the specification. You will find this on the chapter 7 of the mesh specification, and it states that "A device may support the Mesh Provisioning Service or the Mesh Proxy Service or both. If both are supported, only one of these services shall be exposed in the GATT database at a time." Based on this we would be violating the spec if both services are exposed in the GATT Database at a time.

Hope this helps.

Roshan