Hi,
I'm testing meshctl of bluez 5.47 with a lighting device with Silvair mesh stack.
I am able to provision a device using a following sequence of commands:
provision a9d8....(UUID follows)
add-appkey 1
bind 0 1 1000
Im then able to turn the light on and off using onoff 1 / onoff 0. Get also works.
When I'm leaving meshctl and start it once again, it fails while parsing provisioner_db.json
I found out that the problem was caused by:
"bind":[
1
]
in nodes/elements/models
When I remove "bind" element, everything seems to work fine.
Is it a bug in the software or am I doing something wrong?
Attaching configuration files.
Regards,
Michal Hobot
Hi Michal,
On Mon, Nov 27, 2017, Stotland, Inga wrote:
> On Fri, 2017-11-24 at 22:13 +0100, Michał Hobot wrote:
> > Btw, should I post an official patch? I'm new to this group.
>
> Yes, please go ahead and submit an official patch using git send-email.
Will you be submitting git-formatted patch for this? It's one of the
last few remaining patches I'd like to get merged before we create a new
BlueZ release.
Johan
Hi Michal,
On Fri, 2017-11-24 at 22:13 +0100, Michał Hobot wrote:
> Inga,
> I think I found root cause of the problem. There is a bug in a way
> custom models are parsed, so parsing fails quietly and correct
> information doesn't get written to the provisioner db.
> This happens only when there is more than one custom model in
> composition data.
>
> The patch is pretty trivial and self-explanatory:
>
> --- bluez.orig/mesh/node.c 2017-11-21 18:04:57.000000000 +0100
> +++ bluez/mesh/node.c 2017-11-24 21:37:16.000000000 +0100
> @@ -432,7 +432,7 @@ bool node_parse_composition(struct mesh_
> len -= 2;
> }
> while (len >= 4 && v--) {
> - mod_id = get_le16(data);
> + mod_id = get_le16(data + 2);
> vendor_id = get_le16(data);
> mod_id |= (vendor_id << 16);
> if (!node_set_model(node, ele->index,
> mod_id))
>
>
> Identical error prevents composition data from being printed out
> correctly:
>
> --- bluez.orig/mesh/prov-db.c 2017-11-21 18:04:57.000000000
> +0100
> +++ bluez/mesh/prov-db.c 2017-11-24 21:36:12.000000000 +0100
> @@ -676,7 +676,7 @@ bool prov_db_add_node_composition(struct
> }
>
> while (len >= 4 && v--) {
> - mod_id = get_le16(data);
> + mod_id = get_le16(data + 2);
> vendor_id = get_le16(data);
> mod_id |= (vendor_id << 16);
> data += 4;
>
>
> Btw, should I post an official patch? I'm new to this group.
>
> Regards,
> Michal Hobot
>
>
> > Wiadomość napisana przez Stotland, Inga <[email protected]> w
> > dniu 21.11.2017, o godz. 08:25:
> >
> > Hi Michal,
> >
> > On Mon, 2017-11-20 at 19:19 +0100, Michał Hobot wrote:
> > > Hi,
> > > I'm testing meshctl of bluez 5.47 with a lighting device with
> > > Silvair
> > > mesh stack.
> > > I am able to provision a device using a following sequence of
> > > commands:
> > >
> > > provision a9d8....(UUID follows)
> > > add-appkey 1
> > > bind 0 1 1000
> > >
> > > Im then able to turn the light on and off using onoff 1 / onoff
> > > 0.
> > > Get also works.
> > >
> > > When I'm leaving meshctl and start it once again, it fails while
> > > parsing provisioner_db.json
> > >
> > > I found out that the problem was caused by:
> > >
> > > "bind":[
> > > 1
> > > ]
> > >
> > > in nodes/elements/models
> > > When I remove "bind" element, everything seems to work fine.
> > >
> > > Is it a bug in the software or am I doing something wrong?
> > >
> > > Attaching configuration files.
> > >
> > > Regards,
> > > Michal Hobot
> > >
> >
> > Looks like you discovered a loophole: the provisioner
> > should not try to issue any configuration commands that require
> > knowledge of model/element setup on the node without first getting
> > node
> > composition. The result is a malformed database.
> >
> > I submitted a patch: "[PATCH BlueZ] mesh: validate configuration
> > target" to address this issue.
> >
> > Meanwhile, I suggest calling "get-composition" command prior to any
> > config command that deals with models.
> >
> > Thanks,
> >
> > Inga
>
>
Yes, please go ahead and submit an official patch using git send-email.
Thank you,
Inga
Inga,
I think I found root cause of the problem. There is a bug in a way =
custom models are parsed, so parsing fails quietly and correct =
information doesn't get written to the provisioner db.
This happens only when there is more than one custom model in =
composition data.
The patch is pretty trivial and self-explanatory:
--- bluez.orig/mesh/node.c 2017-11-21 18:04:57.000000000 +0100
+++ bluez/mesh/node.c 2017-11-24 21:37:16.000000000 +0100
@@ -432,7 +432,7 @@ bool node_parse_composition(struct mesh_
len -=3D 2;
}
while (len >=3D 4 && v--) {
- mod_id =3D get_le16(data);
+ mod_id =3D get_le16(data + 2);
vendor_id =3D get_le16(data);
mod_id |=3D (vendor_id << 16);
if (!node_set_model(node, ele->index, mod_id))
Identical error prevents composition data from being printed out =
correctly:
--- bluez.orig/mesh/prov-db.c 2017-11-21 18:04:57.000000000 +0100
+++ bluez/mesh/prov-db.c 2017-11-24 21:36:12.000000000 +0100
@@ -676,7 +676,7 @@ bool prov_db_add_node_composition(struct
}
=20
while (len >=3D 4 && v--) {
- mod_id =3D get_le16(data);
+ mod_id =3D get_le16(data + 2);
vendor_id =3D get_le16(data);
mod_id |=3D (vendor_id << 16);
data +=3D 4;
Btw, should I post an official patch? I'm new to this group.
Regards,
Michal Hobot
> Wiadomo=C5=9B=C4=87 napisana przez Stotland, Inga =
<[email protected]> w dniu 21.11.2017, o godz. 08:25:
>=20
> Hi Michal,
>=20
> On Mon, 2017-11-20 at 19:19 +0100, Micha=C5=82 Hobot wrote:
>> Hi,
>> I'm testing meshctl of bluez 5.47 with a lighting device with Silvair
>> mesh stack.
>> I am able to provision a device using a following sequence of
>> commands:
>>=20
>> provision a9d8....(UUID follows)
>> add-appkey 1
>> bind 0 1 1000
>>=20
>> Im then able to turn the light on and off using onoff 1 / onoff 0.
>> Get also works.
>>=20
>> When I'm leaving meshctl and start it once again, it fails while
>> parsing provisioner_db.json
>>=20
>> I found out that the problem was caused by:
>>=20
>> "bind":[
>> 1
>> ]
>>=20
>> in nodes/elements/models
>> When I remove "bind" element, everything seems to work fine.
>>=20
>> Is it a bug in the software or am I doing something wrong?
>>=20
>> Attaching configuration files.
>>=20
>> Regards,
>> Michal Hobot
>>=20
> Looks like you discovered a loophole: the provisioner
> should not try to issue any configuration commands that require
> knowledge of model/element setup on the node without first getting =
node
> composition. The result is a malformed database.
>=20
> I submitted a patch: "[PATCH BlueZ] mesh: validate configuration
> target" to address this issue.
>=20
> Meanwhile, I suggest calling "get-composition" command prior to any
> config command that deals with models.
>=20
> Thanks,
>=20
> Inga
Hi Michal,
On Mon, 2017-11-20 at 19:19 +0100, Michał Hobot wrote:
> Hi,
> I'm testing meshctl of bluez 5.47 with a lighting device with Silvair
> mesh stack.
> I am able to provision a device using a following sequence of
> commands:
>
> provision a9d8....(UUID follows)
> add-appkey 1
> bind 0 1 1000
>
> Im then able to turn the light on and off using onoff 1 / onoff 0.
> Get also works.
>
> When I'm leaving meshctl and start it once again, it fails while
> parsing provisioner_db.json
>
> I found out that the problem was caused by:
>
> "bind":[
> 1
> ]
>
> in nodes/elements/models
> When I remove "bind" element, everything seems to work fine.
>
> Is it a bug in the software or am I doing something wrong?
>
> Attaching configuration files.
>
> Regards,
> Michal Hobot
>
Looks like you discovered a loophole: the provisioner
should not try to issue any configuration commands that require
knowledge of model/element setup on the node without first getting node
composition. The result is a malformed database.
I submitted a patch: "[PATCH BlueZ] mesh: validate configuration
target" to address this issue.
Meanwhile, I suggest calling "get-composition" command prior to any
config command that deals with models.
Thanks,
Inga