Re: Unsolicited Notify with newtmgr over BLE

[Vipul Rahane]

Hello Kevin,

Thank you for going through this.

I agree with what Chris mentioned. When I wrote the newtmgr protocol(NMP) in 
swift for Nordic’s Toolbox app, I had enabled this bit for the newtmgr 
characteristic. The port is still WIP and hence the incompleteness. I have 
spoken to Chris about this and will set the notify bit on the newtmgr 
characteristic. 

As for the UUIDs, I agree that making the first 16 bits sequential does sound 
intuitive but then the IDs would not be truely unique and there would be a 
higher probability of a collision. I have generated the currently assigned IDs 
using Guid generator  which generates the IDs 
based on an algorithm that is mentioned in RFC4122 
 and it uses the timestamp and the MAC 
address of the computer they were generated on. 

Regards,
Vipul Rahane 

> On Oct 5, 2016, at 7:36 PM, Kevin Townsend  wrote:
> 
> 
>> I think you're right about that - a CCCD should not be set to one unless
>> the peer writes to it.  What I'm not so sure about is whether it is
>> prohibited to send a notification to an unsubscribed peer.  I didn't see
>> any language in the spec indicating that this is illegal.  The ability
>> to send unsolicited notifications is useful, and I don't see a reason
>> why it shouldn't be allowed.
> I agree it's somewhat ambiguous or open to interpretation at present,
> but in the case of something as critical as newtmgr over ble (OTA DFU
> etc.), it probably makes sense to take the safe approach and add the
> CCCD to a characteristic and have the peer explicitly set the notify
> bit before the response data is sent???
> 
> Having the possibility to send unsolicited notifies has some merit, and
> personally I don't have any objections to it being included as an option
> in nimble, but I wouldn't rely on those assumptions for newtmgr over
> BLE.
> 
> Just my opinion though and curious to hear what other people think.

Re: Unsolicited Notify with newtmgr over BLE

[Kevin Townsend]

I think you're right about that - a CCCD should not be set to one unless
the peer writes to it.  What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer.  I didn't see
any language in the spec indicating that this is illegal.  The ability
to send unsolicited notifications is useful, and I don't see a reason
why it shouldn't be allowed.

I agree it's somewhat ambiguous or open to interpretation at present,
but in the case of something as critical as newtmgr over ble (OTA DFU
etc.), it probably makes sense to take the safe approach and add the
CCCD to a characteristic and have the peer explicitly set the notify
bit before the response data is sent???

Having the possibility to send unsolicited notifies has some merit, and
personally I don't have any objections to it being included as an option
in nimble, but I wouldn't rely on those assumptions for newtmgr over
BLE.

Just my opinion though and curious to hear what other people think.

Re: Unsolicited Notify with newtmgr over BLE

[Christopher Collins]

On Wed, Oct 05, 2016 at 05:07:00PM -0700, Mike Ryan wrote:
> On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> > I remember some discussions previously about unsolicited notifies
> > and whether this was or wasn't supported in the BLE spec
> 
> My reading of the spec suggests that it is not legal. Referring to
> Client Characteristic Configuration on PDF page 2228 of Core v4.2 (Vol.
> 3 Part G Sec 3.3.3.3):
> 
> > The Client Characteristic Configuration descriptor value shall be set
> > to the default value at each connection with non-bonded devices.
> 
> Later in the same section:
> 
> > The default value for the Client Characteristic Configuration
> > descriptor value shall be 0x.
> 
> This suggests that the value for notifications will be 0. A value of 1
> signifies "the Characteristic Value shall be notified". It's safe to
> assume that a value of 0 therefore means that the value shall not be
> notified.

I think you're right about that - a CCCD should not be set to one unless
the peer writes to it.  What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer.  I didn't see
any language in the spec indicating that this is illegal.  The ability
to send unsolicited notifications is useful, and I don't see a reason
why it shouldn't be allowed.

That said, I believe iOS will drop incoming notifications for a
characteristic that doesn't have a CCCD.  I don't believe android has
this limitation.  If iOS requires the characteristic to be subscribable,
then I think we need to comply.

Thanks,
Chris

Re: Unsolicited Notify with newtmgr over BLE

[Kevin Townsend]

Also, would it make sense to have more consistent UUIDs, such as:

- 8D530001-1DB7-4CD3-868B-8A527460AA84
- 8D530002-1DB7-4CD3-868B-8A527460AA84
- 8D530003-1DB7-4CD3-868B-8A527460AA84 (potentially?)

We could perhaps even settle on a single base 128-bit UUID throughout 
Mynewt, adjusting the 16 bit range at the start?


This is a minor detail and might be a nuisance to change, and more of a 
cosmetic issue, but I figured it was worth tossing out there.



On 06/10/16 02:00, Kevin Townsend wrote:
I'm working with newtmgr over BLE based on the newtmgr lib in the 
master branch of apache-mynewt-core, which currently has the following 
structure:


Service UUID: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
Characteristic UUID: DA2E7828-FBCE-4E01-AE9E-261174997C48

The source code has this explanatory comment on the service:

> The "newtmgr" service consists of one write no-rsp characteristic for
> newtmgr requests: a single-byte characteristic that can only accepts
> write-without-response commands. The contents of each write command
> contains an NMP request. NMP responses are sent back in the form of
> unsolicited notifications from the same characteristic.

I remember some discussions previously about unsolicited notifies and 
whether this was or wasn't supported in the BLE spec (I believe 
between Carles Cufi from Nordic and I believe Will and/or Chris at 
Runtime?), but given the uncertainty around this I wonder if it 
wouldn't be better to adjust the newtmgr service definition to have 
two characteristics similar to the way 'nus' (Nordic UART Service) works:


- One TXD or 'Request' characteristic to write commands to, which can 
reuse the existing characteristic as-is
- A new RXD or 'Response' characteristic with notify enabled, which 
would also allow you to send multiple data chunks since each packet 
will cause a new notify event on the Central, making it relatively 
easy to manage rebuilding packets.


I've been doing some initial tests with the netmgr service as is and 
many apps don't seem to like the unsolicited notifications even if 
they can be made to work.  Two separate characteristics would probably 
ensure everything is handled unambiguously on any platform, but I'm 
curious to hear other people's thoughts?


Kevin

Re: Unsolicited Notify with newtmgr over BLE

[Mike Ryan]

On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> I remember some discussions previously about unsolicited notifies
> and whether this was or wasn't supported in the BLE spec

My reading of the spec suggests that it is not legal. Referring to
Client Characteristic Configuration on PDF page 2228 of Core v4.2 (Vol.
3 Part G Sec 3.3.3.3):

> The Client Characteristic Configuration descriptor value shall be set
> to the default value at each connection with non-bonded devices.

Later in the same section:

> The default value for the Client Characteristic Configuration
> descriptor value shall be 0x.

This suggests that the value for notifications will be 0. A value of 1
signifies "the Characteristic Value shall be notified". It's safe to
assume that a value of 0 therefore means that the value shall not be
notified.