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 <inga.stotland@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
