Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
* mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
@ 2019-08-30 18:43 Michał Lowas-Rzechonek
  2019-09-04 19:25 ` Michał Lowas-Rzechonek
  2019-09-18  8:52 ` Michał Lowas-Rzechonek
  0 siblings, 2 replies; 9+ messages in thread
From: Michał Lowas-Rzechonek @ 2019-08-30 18:43 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

When trying to use subscriptions in meshd, I've noticed that
MessageReceived API does not provide the application with destination
address of the deceived message - instead, it only sends a boolean flag
saying if the message was part of a model subscription, or not.

I think this is problematic. There are use cases where a model is
interested in the destination address of a group subscription. For
example:

Imagine a dot-matrix, where each pixel is a mesh node.

Each of these pixels implements two models:
    on element 0, a GenericOnOffServer controlling the light output
    on element 1, a Blinkenlights Server model

Blinkenlights Server extends GenericOnOff Server and GenericOnOff
Client, and on top of that contains a translation table mapping group
address to either 'ON' or 'OFF'.

Now, when Blinkenlights Server receives a GenericOnOff Set message, it
looks up the destination address at the translation table, and sends a
*different* GenericOnOff Set to *its own* element 0, with target value
determined by the translation entry.

This allows users to configure each node in such a way, that sending a
*single* message to a group address causes all pixels to switch to a
preconfigured pattern *at the same time*.

Moreover, at the moment the application can't receive the label of a
virtual address the message is targeted to.


I'd like to discuss the API change, from the current:

	void MessageReceived(uint16 source, uint16 key_index,
					boolean subscription, array{byte} data)

to something like:

	void MessageReceived(uint16 source, uint16 destination,
                    uint16 key_index, array{byte} data)

	void VirtMessageReceived(uint16 source, array{byte}[16] label,
                    uint16 key_index, array{byte} data)

thoughts?
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-08-30 18:43 mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address Michał Lowas-Rzechonek
@ 2019-09-04 19:25 ` Michał Lowas-Rzechonek
  2019-09-04 19:48   ` Michał Lowas-Rzechonek
  2019-09-18  8:52 ` Michał Lowas-Rzechonek
  1 sibling, 1 reply; 9+ messages in thread
From: Michał Lowas-Rzechonek @ 2019-09-04 19:25 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Brian Gix, Inga Stotland, Szymon Słupik

Hello,

On 08/30, Michał Lowas-Rzechonek wrote:
> When trying to use subscriptions in meshd, I've noticed that
> MessageReceived API does not provide the application with destination
> address of the deceived message - instead, it only sends a boolean flag
> saying if the message was part of a model subscription, or not.
> 
> I think this is problematic. There are use cases where a model is
> interested in the destination address of a group subscription. For
> example:

Alright, so it seems that is not as straightforward as I would like it
to be...

First of all, it seems that the specification doesn't *strictly* require
the model to know the value of the destination address of received
messages. The only passage that somewhat relates to that is in Mesh
Models spec v1.0.1, 3.3.2.2.3 "Receiving Generic Delta Set", but at the
moment we think that the requirement about aborting transacations
specified there can be satisfied without knowing the numeric value of a
destination address.

Other things have been neatly summarized by Brian, so I'm gonna respond
as usual.

On 09/04, Gix, Brian wrote:
> Well, what we are trying to balance here is:
>
> 1. Keeping the APIs as simple as possible

Yes, but not simpler...

> 2. Not exposing any information that we don't absolutely need to

And this is the thing I simply don't agree with. Security in mesh is
based on *keys*, not *APIs*.

We discussed access to the keyring before and I kind of agree that
applications don't really need access to key values, as long as various
Import*() methods exist. So keys are covered.

But hiding anything else does not make any sense. Certainly, it doesn't
"increase security" by any means. There is no reason why a model should
not have access to pretty much the whole payload (once it passes all the
layers, subscriptions and bindings are verified etc)., a complete
network layer included.

My primary argument is this: BT mesh is a relatively young standard and
apart from what's in Mesh Models spec we don't see many applications in
the wild. Who knows what the people are going to do with it? One of the
reasons we would like BT mesh to be available as free software is to
enable various people to play with it and invent new, interesting
applications (ideally, they would make it back to SIG and be adopted as
official specification, but that's another story).

In my opinion, keeping that power away from users, because there is no
"official" spec that uses certain information, is harmful.

> 3. Enabling valid use cases.
>
> We also are trying to stay true to the *spirit* of the specifications,
> and so I get a little uncomfortable with arguments like "The spec
> doesn't explicitely disallow it, so we need to support it".

And who gets to decide which use cases are "valid" and "true to the
spirit"?

The two examples I provided are *not* violating the spec in any way.
For the record:
 - a combined server/client sitting on element 1 that receives onoff
   messages and, depending on the destination address, sends a different
   onoff messages to a "regular" onoff server sitting on element 0,
   allowing efficient control over switching scenes involving large
   number of nodes
 - a model that acts as a IPv6 gateway and directly maps virtual
   addresses to IPv6 addresses of nodes living on the other side of the
   gateway

> That said, in this case we are proposing substituting a boolean
> argument (called "subscription", but really just a differentiator
> between a message received as a Unicast message vs a Group or Virtual
> address) with the actual destrination address. If this was as simple
> as a parameter swap, I would say "Go for it", but because of Virtual
> Addresses, it means substituting *two* methods for the one.  Then to
> continue down the rabbit hole, every *App* needs to support both
> methods which increases their complexity as well.

Well, if the application is not using virtual addresses then it doesn't
need to implement the method.

> I remember having this conversation just between Inga and myself when
> designing the interface, which is why we went for the Boolean
> argument...  to keep the API simpler in both the Applications and in
> the Daemon.  But if we are *absolutely sure* that there are valid Use
> Cases that *require* the knowledge of *which* subscription a message
> was received with, then we may have no choice.
>
> Some of the use-cases suggested I believe are invalid...  Multiple
> models on the same element are not allowed to execute the same
> opcode... or at least not ones that change a local state.

Could you elaborate? The two examples above don't require executing the
same opcode on different models.

The first one (in a slightly different form, but the idea is the same)
is already deployed in a production environment.

> This is Inga's area of expertice (both on the App side and the Daemon
> side) so I am inclined to trust her judgement.  But I would *really*
> like to avoid adding yet another MessageRecieved method if possibled.

We could make the address a D-Bus variant. I proposed two methods,
because I find variants somewhat cumbersome, but I have no strong
opinion about that.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-04 19:25 ` Michał Lowas-Rzechonek
@ 2019-09-04 19:48   ` Michał Lowas-Rzechonek
  2019-09-04 20:26     ` Gix, Brian
  0 siblings, 1 reply; 9+ messages in thread
From: Michał Lowas-Rzechonek @ 2019-09-04 19:48 UTC (permalink / raw)
  To: linux-bluetooth, Brian Gix, Inga Stotland, Szymon Słupik

On 09/04, Michał Lowas-Rzechonek wrote:
> The two examples I provided are *not* violating the spec in any way.
> For the record:
>  - a combined server/client sitting on element 1 that receives onoff
>    messages and, depending on the destination address, sends a different
>    onoff messages to a "regular" onoff server sitting on element 0,
>    allowing efficient control over switching scenes involving large
>    number of nodes
>  - a model that acts as a IPv6 gateway and directly maps virtual
>    addresses to IPv6 addresses of nodes living on the other side of the
>    gateway

Another one about virtual addresses:

In CANOpen, there is a concept of a "Protocol Data Object" [1].
Basically, the idea is to pack many pieces of information into a
preconfigured format (down to single bits, because CAN frames are even
shorter than mesh ones) - this is known as "PDO Mapping Parameters" -
then send such payloads to a well-known group address.

In static configurations, this allows to decrease the number (and size)
of packets sent by sensor nodes.

Since PDO payloads are *not* self-describing (unlike mesh sensor
messages), the receiving party must be aware of the mapping in order to
parse the data.

In CANOpen, format is determined by the address - in mesh, it could very
well be a virtual label.

[1] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-04 19:48   ` Michał Lowas-Rzechonek
@ 2019-09-04 20:26     ` Gix, Brian
  2019-09-04 22:39       ` Stotland, Inga
  2019-09-05  7:34       ` michal.lowas-rzechonek
  0 siblings, 2 replies; 9+ messages in thread
From: Gix, Brian @ 2019-09-04 20:26 UTC (permalink / raw)
  To: michal.lowas-rzechonek, linux-bluetooth, Stotland, Inga, simon

On Wed, 2019-09-04 at 21:48 +0200, Michał Lowas-Rzechonek wrote:
> On 09/04, Michał Lowas-Rzechonek wrote:
> > The two examples I provided are *not* violating the spec in any way.
> > For the record:
> >  - a combined server/client sitting on element 1 that receives onoff
> >    messages and, depending on the destination address, sends a different
> >    onoff messages to a "regular" onoff server sitting on element 0,
> >    allowing efficient control over switching scenes involving large
> >    number of nodes
> >  - a model that acts as a IPv6 gateway and directly maps virtual
> >    addresses to IPv6 addresses of nodes living on the other side of the
> >    gateway
> 
> Another one about virtual addresses:
> 
> In CANOpen, there is a concept of a "Protocol Data Object" [1].
> Basically, the idea is to pack many pieces of information into a
> preconfigured format (down to single bits, because CAN frames are even
> shorter than mesh ones) - this is known as "PDO Mapping Parameters" -
> then send such payloads to a well-known group address.
> 
> In static configurations, this allows to decrease the number (and size)
> of packets sent by sensor nodes.
> 
> Since PDO payloads are *not* self-describing (unlike mesh sensor
> messages), the receiving party must be aware of the mapping in order to
> parse the data.
> 
> In CANOpen, format is determined by the address - in mesh, it could very
> well be a virtual label.
> 
> [1] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
> 

I think that this is an interesting use of Virtual Addresses, and in addition to this, Mesh Virtual Addresses
have been suggested as a way of addressing IPv6 addressing as well...  However:

1. There is already a way something like this could be used already:  A model could be created that gets
subscribed to the Virtual Addresses that require handling by the node.

2. If such a system proves to be widely requested, daemon support could be added (perhaps under a different
DBus interface) for either or both of IPv6 and "CANOpen".

In any case the ability to create simple mesh Apps with minimal complexity remains intact, and as an added
bonus, the Open Source community (not to mention the Bluetooth Mesh Working Group and larger SIG) can weigh in
on the preferred methodologies.






^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-04 20:26     ` Gix, Brian
@ 2019-09-04 22:39       ` Stotland, Inga
  2019-09-05  7:29         ` michal.lowas-rzechonek
  2019-09-05  7:34       ` michal.lowas-rzechonek
  1 sibling, 1 reply; 9+ messages in thread
From: Stotland, Inga @ 2019-09-04 22:39 UTC (permalink / raw)
  To: michal.lowas-rzechonek, linux-bluetooth, Gix, Brian, simon

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

Hi,

On Wed, 2019-09-04 at 13:26 -0700, Gix, Brian wrote:
> On Wed, 2019-09-04 at 21:48 +0200, Michał Lowas-Rzechonek wrote:
> > On 09/04, Michał Lowas-Rzechonek wrote:
> > > The two examples I provided are *not* violating the spec in any
> > > way.
> > > For the record:
> > >  - a combined server/client sitting on element 1 that receives
> > > onoff
> > >    messages and, depending on the destination address, sends a
> > > different
> > >    onoff messages to a "regular" onoff server sitting on element
> > > 0,
> > >    allowing efficient control over switching scenes involving
> > > large
> > >    number of nodes


This sounds like something a vendor model mechanism should handle:
the "mapping" should be understood on both ends: client and server.


> > >  - a model that acts as a IPv6 gateway and directly maps virtual
> > >    addresses to IPv6 addresses of nodes living on the other side
> > > of the
> > >    gateway
> > 
> > Another one about virtual addresses:
> > 
> > In CANOpen, there is a concept of a "Protocol Data Object" [1].
> > Basically, the idea is to pack many pieces of information into a
> > preconfigured format (down to single bits, because CAN frames are
> > even
> > shorter than mesh ones) - this is known as "PDO Mapping Parameters"
> > -
> > then send such payloads to a well-known group address.
> > 
> > In static configurations, this allows to decrease the number (and
> > size)
> > of packets sent by sensor nodes.
> > 
> > Since PDO payloads are *not* self-describing (unlike mesh sensor
> > messages), the receiving party must be aware of the mapping in
> > order to
> > parse the data.
> > 
> > In CANOpen, format is determined by the address - in mesh, it could
> > very
> > well be a virtual label.
> > 
> > [1] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
> > 
> 
> I think that this is an interesting use of Virtual Addresses, and in
> addition to this, Mesh Virtual Addresses
> have been suggested as a way of addressing IPv6 addressing as
> well...  However:
> 
> 1. There is already a way something like this could be used
> already:  A model could be created that gets
> subscribed to the Virtual Addresses that require handling by the
> node.
> 
> 2. If such a system proves to be widely requested, daemon support
> could be added (perhaps under a different
> DBus interface) for either or both of IPv6 and "CANOpen".
> 
> In any case the ability to create simple mesh Apps with minimal
> complexity remains intact, and as an added
> bonus, the Open Source community (not to mention the Bluetooth Mesh
> Working Group and larger SIG) can weigh in
> on the preferred methodologies.
> 

My feeling is that the API should be geared towards common case
scenarios (i.e., defined models and such). 

If there is a behavior that absolutely cannot be addressed with the
current API (and use of vendor models), then it has to be
changed/augmented.

As such, I still don't see a compelling reason to do so.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-04 22:39       ` Stotland, Inga
@ 2019-09-05  7:29         ` michal.lowas-rzechonek
  0 siblings, 0 replies; 9+ messages in thread
From: michal.lowas-rzechonek @ 2019-09-05  7:29 UTC (permalink / raw)
  To: Stotland, Inga; +Cc: linux-bluetooth, Gix, Brian, simon

Hi Inga,

On 09/04, Stotland, Inga wrote:
> > > >  - a combined server/client sitting on element 1 that receives
> > > >  onoff messages and, depending on the destination address, sends
> > > >  a different onoff messages to a "regular" onoff server sitting
> > > >  on element 0, allowing efficient control over switching scenes
> > > >  involving large number of nodes
> This sounds like something a vendor model mechanism should handle:
> the "mapping" should be understood on both ends: client and server.

Well, yes, I've described a vendor model... one that uses destination
group addresses to 'understand' the mapping.

I don't get what other mechanism do you have in mind?

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-04 20:26     ` Gix, Brian
  2019-09-04 22:39       ` Stotland, Inga
@ 2019-09-05  7:34       ` michal.lowas-rzechonek
  1 sibling, 0 replies; 9+ messages in thread
From: michal.lowas-rzechonek @ 2019-09-05  7:34 UTC (permalink / raw)
  To: Gix, Brian; +Cc: linux-bluetooth, Stotland, Inga, simon

Hi Brian,

On 09/04, Gix, Brian wrote:
> > Since PDO payloads are *not* self-describing (unlike mesh sensor
> > messages), the receiving party must be aware of the mapping in order to
> > parse the data.
> > 
> > In CANOpen, format is determined by the address - in mesh, it could very
> > well be a virtual label.
> 
> I think that this is an interesting use of Virtual Addresses, and in
> addition to this, Mesh Virtual Addresses have been suggested as a way
> of addressing IPv6 addressing as well...  However:
> 
> 1. There is already a way something like this could be used already:
>    A model could be created that gets subscribed to the Virtual
>    Addresses that require handling by the node.

But the whole idea is that the virtual labels and packing are configured
dynamically (by the commissioner) according to their specific needs.

If a model doesn't receive the *value* of the label, you would need a
separate model for each of the virtuals. This is problematic, because
composition data is immutable, so you wouldn't be able to reconfigure
these mappings without at least re-provisioning the whole network.

> In any case the ability to create simple mesh Apps with minimal
> complexity remains intact, and as an added bonus, the Open Source
> community (not to mention the Bluetooth Mesh Working Group and larger
> SIG) can weigh in on the preferred methodologies.

Aren't *we* the community? :P

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-08-30 18:43 mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address Michał Lowas-Rzechonek
  2019-09-04 19:25 ` Michał Lowas-Rzechonek
@ 2019-09-18  8:52 ` Michał Lowas-Rzechonek
  2019-09-18 12:36   ` Michał Lowas-Rzechonek
  1 sibling, 1 reply; 9+ messages in thread
From: Michał Lowas-Rzechonek @ 2019-09-18  8:52 UTC (permalink / raw)
  To: Brian Gix, Inga Stotland, linux-bluetooth, Piotr Winiarczyk,
	Szymon Słupik

Hi Brian,

> Imagine a dot-matrix, where each pixel is a mesh node.
> 
> Each of these pixels implements two models:
>     on element 0, a GenericOnOffServer controlling the light output
>     on element 1, a Blinkenlights Server model
> 
> Blinkenlights Server extends GenericOnOff Server and GenericOnOff
> Client, and on top of that contains a translation table mapping group
> address to either 'ON' or 'OFF'.
> 
> Now, when Blinkenlights Server receives a GenericOnOff Set message, it
> looks up the destination address at the translation table, and sends a
> *different* GenericOnOff Set to *its own* element 0, with target value
> determined by the translation entry.
> 
> This allows users to configure each node in such a way, that sending a
> *single* message to a group address causes all pixels to switch to a
> preconfigured pattern *at the same time*.

Per conversation with Piotr, I'd like to revisit the discussion and
provide more details about our use case for models knowing the
destination address.

Please see a diagram at http://ujeb.se/BmTIW.

The main reason we map scenes using destination addresses is that such a
setup consumes much less unicast addresses.

Assuming that:
 S - number of switches
 B - number of buttons (elements) on a switch
 N - nunber of lamps

With a 'regular' case, number of consumed unicast addresses is
    S*B + N*(B+1)

With the destination mapping, it becomes
    S*B + N*2

Since we typically use 4 button switches (B=4), without translation we
consume unicast address space at a *much* faster rate.

reagrds
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address
  2019-09-18  8:52 ` Michał Lowas-Rzechonek
@ 2019-09-18 12:36   ` Michał Lowas-Rzechonek
  0 siblings, 0 replies; 9+ messages in thread
From: Michał Lowas-Rzechonek @ 2019-09-18 12:36 UTC (permalink / raw)
  To: Brian Gix, Inga Stotland, linux-bluetooth, Piotr Winiarczyk,
	Szymon Słupik

On 09/18, Michał Lowas-Rzechonek wrote:
> Please see a diagram at http://ujeb.se/BmTIW.

If you have trouble accesing the drawing, here are PNGs:

https://drive.google.com/file/d/1zZrmFB7NLcbyR-tPE9ljqxolZIonxXbc/view
https://drive.google.com/file/d/1ntkJGU1SYtgqrmQN9F4PDiWdjYAc0U8o/view

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-30 18:43 mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address Michał Lowas-Rzechonek
2019-09-04 19:25 ` Michał Lowas-Rzechonek
2019-09-04 19:48   ` Michał Lowas-Rzechonek
2019-09-04 20:26     ` Gix, Brian
2019-09-04 22:39       ` Stotland, Inga
2019-09-05  7:29         ` michal.lowas-rzechonek
2019-09-05  7:34       ` michal.lowas-rzechonek
2019-09-18  8:52 ` Michał Lowas-Rzechonek
2019-09-18 12:36   ` Michał Lowas-Rzechonek

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org linux-bluetooth@archiver.kernel.org
	public-inbox-index linux-bluetooth


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/ public-inbox