Zephyr: Bluetooth: Mesh: onoff_level_lighting_vnd sample fails provisioning

[Ripitchip]

Describe the bug
Trying to run the mesh sample described here : sample Mesh Generic OnOff, Generic Level, Lighting & Vendor Models

To Reproduce
Steps to reproduce the behavior:

1. cd zephyrproject/zephyr
2. west build -b nrf52840dk_nrf52840 samples/boards/nrf/mesh/onoff_level_lighting_vnd_app
3. west flash --erase

Expected behavior
I expect to be able to provision the device through meshctl of BlueZ. It's not the case.
The connection to the device is successful but the provisioning itself fails. Cf. Log of the meshctl and Nrf52840.
LogMeshctl.txt
LogNrf52840.txt

I tried with two different Nrf52840. I even tried on another Linux (virtual machine) - same problem. The another sample onoff-app was working though.

Btw, can I know where I can find the mesh implementation of the API ? I couldn't find for example _struct bt_mesh_model_op_ which is noted here here but not really described.

Impact
Can't prove the extraordinary benefit of bluetooth mesh and Zephyr OS to my chief project :)

Logs and console output
If applicable, add console logs or other types of debug information
e.g Wireshark capture or Logic analyzer capture (upload in zip archive).
copy-and-paste text and put a code fence (```) before and after, to help
explain the issue. (if unable to obtain text log, add a screenshot)

Environment (please complete the following information):

• OS: Ubuntu 20.04 LTS
• Zephyr SDK (0.11.3)
• Zephyr version 2.4.0-rc1
• We have the nRF52840 DK.

[LingaoM]

Hi, i saw your log and found no problem, but I noticed that you are using the lowest security level(NO OOB) for provisioning. Do you set the security level of meshctl?

security 0 should be set for this level security.

[LingaoM]

https://github.com/zephyrproject-rtos/zephyr/tree/master/include/bluetooth/mesh
All mesh related definitions are included here.

For example, if you want to know about bt_mesh_model_op, you can look at access.h.

[Ripitchip]

Hello,

Thanks for quick answer.

Yes you were right. Changing meshctl security level permitted me to do the provisioning so I could run the sample.

Several questions though :

• For my own understanding : why is the security level important with this sample opposed as the "onoff-app" sample which could run without me setting anything ?

• It's written that before provisioning "Each button controls the state of its corresponding LED". In my case, that's wasn't like that as it would display "bt_mesh_model_publish: err: -49" on minicom terminal. Is that normal ?

• After provisioning I could set up the generic on/off and light models as shown in the documentation. However, I had difficulties to set up the vendor model.
  First I tried with meshctl to do as follow :

1. discover-unprovisioned on
2. provision
3. menu config
4. target 0100
5. appkey-add 1
6. bind 0 1 4321 0002
7. pub-set 0100 c000 1 0 5 4321 0002

So far, it worked but then I wanted to do

1. pub-set 0100 c000 1 0 5 4321 0002

To my surprise, I saw that meshctl doesn't provide a sub-set with [cid] parameter.. ?
If I look to all commands in menu config, I can read this :

• pub-set [cid]
• bind [cid]
• sub-add

I've got meshctl v.5.55 (ie. latest version I believe). So it surprises me.

Next, I tried with nRF connect nRF Mesh app by adding an app key and configuring vendor model of element 1 to publish and subscribe on group 0xC000. It didn't do anything as it would still display "bt_mesh_model_publish: err: -49" on minicom terminal.

I'm a bit lost. Did you manage to setup the vendor model with meshctl only ?

Nice day !

============
Edit : changed the mobile app name as I cited the wrong one.

[trond-snekvik]

why is the security level important with this sample opposed as the "onoff-app" sample which could run without me setting anything ?

Your application does not enable any OOB authentication (as the OOB selection in src/mesh/ble_mesh.c is surrounded by #ifdef OOB_AUTH which is never defined). Without authentication, meshctl rejects your device if you don't lower the security level.

it would display "bt_mesh_model_publish: err: -49" on minicom terminal

This happens if you don't configure the model publication for the model that sends on the button press. Note that none of the models in this sample defines an update callback, so pub-set will fail if you attempt to configure periodic publication. Make sure to check the return value of the pub-set procedure.

I saw that meshctl doesn't provide a sub-set with [cid] parameter

This looks like it has been added pretty recently, you might want to update bluez: https://github.com/bluez/bluez/commit/5474314d895e802ede83c9862c81013707249be2

[Ripitchip]

This looks like it has been added pretty recently, you might want to update bluez: bluez/bluez@5474314

I forgot to mention but I've already got the latest version since the beginning (v. 5.55). Maybe I'll have to ask bluez about this then.

This happens if you don't configure the model publication for the model that sends on the button press. Note that none of the models in this sample defines an update callback, so pub-set will fail if you attempt to configure periodic publication. Make sure to check the return value of the pub-set procedure.

I think I couldn't make myself clear : before provisioning, I can't turn off/on the LEDs like your documentation says.

This happens if you don't configure the model publication for the model that sends on the button press.

I configure it though (well it seems to me). I'm trying with the nRF Mesh app as the meshctl isn't working. I set the publish address of the vendor model to group 0xC000. I set the subscriptions address of the vendor model to group 0xC000. But the buttons still return me the error.
From the app, I can send a get message (opcode 0xC001) and it return me the dummy message as defined in the code (A578FEB3).
What am I still missing to make the sample work ?

[trond-snekvik]

I can't turn off/on the LEDs like your documentation says.

This looks like a discrepancy in the documentation, there's no code to support this in the sample, as far as I can see. @vikrant8051 do you know what happened here?

What am I still missing to make the sample work ?

Error -49 is only returned from bt_mesh_model_publish here, so one of these checks are failing:
https://github.com/zephyrproject-rtos/zephyr/blob/1342d12500867d3de09025037e65e756d5486eba/subsys/bluetooth/mesh/access.c#L741-L748

If possible, try enabling debug logs for foundation models to see what is missing from your publication configuration. It could also be a missing application key

[vikrant8051]

Hi @trond-snekvik
Yes, as per implementation without proper provisioning & configuration of Clients (Buttons), they don't work like in case of onoff-app since buttons functionality is altogether different.

I intentionally did it, so that Clients (Buttons) get isolate from Servers (LEDs). This was necessary during that time for testing & debugging.

So if user want to control LED1 on/off using Button1 (ON) & Button 2 (OFF), then it has to properly configure Gen. OnOff client (on same or different board).

Make sure Client/Server will publish/subscribe to same address :)

Here I will encourage to use nRFMesh App instead of meshclt.

[Ripitchip]

If possible, try enabling debug logs for foundation models to see what is missing from your publication configuration. It could also be a missing application key

I tried to activate the log through the prj.conf file where I uncommented the following lines :
CONFIG_BT_MESH_DEBUG=y
CONFIG_BT_MESH_DEBUG_PROV=y
CONFIG_BT_MESH_DEBUG_MODEL=y
CONFIG_BT_MESH_DEBUG_ACCESS=y
(let me know if others should be uncommented).

In the attached log file you can see the log output for every action I've done to set up the vendor model.
Logs.txt
For me, it seems the application key and publish/subscribe address is set up correctly. It seems kinda similar to the log I get when trying the On/Off model.

I'm able to set up the On/Off model with the behavior described by vikrant8051 just above.

The provisioning and set up was done with nRFMesh App.

==== EDIT :
Btw, with the nRFMesh App there is the possibility to send vendor models controls, so I looked into the code to search for the opcode. I'm able to send the following controls :

opcode : 0xc0|0x01 (get) - with the following log :

[00:57:32.226,715] bt_mesh_access.bt_mesh_model_recv: app_idx 0x0000 src 0x0001 dst 0x0004
[00:57:32.226,745] bt_mesh_access.bt_mesh_model_recv: len 3: c10200
[00:57:32.226,745] bt_mesh_access.bt_mesh_model_recv: OpCode 0x00c10002
[00:57:32.227,966] bt_mesh_access.model_send: net_idx 0x0000 app_idx 0x0000 dst 0x0001
[00:57:32.227,996] bt_mesh_access.model_send: len 9: c402000000b3fe78a5
[00:57:32.228,240] bt_mesh_access.bt_mesh_model_recv: No OpCode 0x00c10002 for elem 1

opcode : 0xc0|0x02 (set) with parameter 0x00c20002
Because I set up some print in the code, I could verify the set, unack and get methods were done.
==== END EDIT

they don't work like in case of onoff-app since buttons functionality is altogether different.

I get it now. The documentation should be corrected because as it is now it's a copy paste of onoff-app and it could confuse people like me :)

[vikrant8051]

@carlescufi @trond-snekvik
Issue has resolved & could close now.

[Ripitchip]

It's not resolved...

I'm simply showing up that :
1) If I do the generic on/off app it works as expected.
2) If I do the vendor model it doesn't publish (displaying of error -49, when clicking on a button), even though it seems to me I have the same logs as with on/off app (for adding the app key and publish/subscribe group address). BUT I'm able to send vendors model to one particular device.

[trond-snekvik]

I made a PR removing the pre-provisioning button text from the readme of this sample: https://github.com/zephyrproject-rtos/zephyr/pull/28949

Just to confirm, in publisher.c, you're removing the defines for ONOFF and GENERIC_LEVEL, and defining VND_MODEL_TEST? By default, this module publishes on the onoff model, and the model selection has to be made at compile time.

I'm not able to reproduce with the nRF Mesh app, regardless of which model is compiled in for publishing, so I'd need some more information.
My steps are the same as yours, but I'm only configuring the models that end up sending in publisher.c (based off the defines). I'm able to publish with the onoff client if I use the default defines and set publish parameters for that model.
I'm able to publish with the vendor model if I replace the defines at the top with VND_MODEL_TEST and set publish parameters for that model.

[Ripitchip]

Just to confirm, in publisher.c, you're removing the defines for ONOFF and GENERIC_LEVEL, and defining VND_MODEL_TEST?

Ah ! It's what I was missing ! I though it was enough to set up the model correctly through meshctl or nRF Mesh and didn't see there is a filter in the code.

My bad.

Thanks very much for your help !