Date
1 - 7 of 7
not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl
vikrant8051 <vikrant8051@...>
Hi, I am not able to provision my Devices which is executing sample example at http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/README.html
|
|
Steve Brown
Hi Vikrant,
On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote: Hi,I looked at this too. Provisioning seems to complete, but the proxy service isn't discovered. Meshctl just seems to hang waiting for the discovery to succeed. While this is happening, if I use bluetoothctl to scan and then connect to the node, the callback in meshctl fires and it starts up and functions as expected. It appears that something is amiss with the discovery filter. I believe that the SILABS App uses advertising bearer for provisioning, so it's not conclusive that it working and meshctl failing is definitely a Bluez issue. I checkout an early March version of Bluez and Zephyr. The problem is still there. samples/bluetooth/mesh fails in the same way. I'm not sure where to go from here. Steve
|
|
vikrant8051 <vikrant8051@...>
Hi Steve, Yes, you are right that #meshctl completes provisioning & fails after that.BlueZ 5.48 #meshctl was perfectly working with Zephyr Mesh DEVICEs. But suddenly this old version as well as BlueZ 5.49 are not working as expected with latest Zephyr version examples. So I don't know where is bug exactly present.
On Wed, Apr 18, 2018 at 6:36 PM, Steve Brown <sbrown@...> wrote: Hi Vikrant,
|
|
Steve Brown
Hi Vikrant,
On Wed, 2018-04-18 at 07:06 -0600, Steve Brown wrote: Hi Vikrant,I tracked this down to Zephyr and bisected the problem to commit d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6 Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV Steve
|
|
Hi Steve,
On Wed, Apr 18, 2018, Steve Brown wrote: I tracked this down to Zephyr and bisected the problem to commitDo you have more details on this? Is there a bug with the patch, or just something else that needs to be tuned somewhere? Johan
|
|
Steve Brown
Hi Johan,
On Wed, 2018-04-18 at 11:32 -0700, Johan Hedberg wrote: Hi Steve,I think the patch exposes a problem with meshctl. Vikrant offers that the SILABS App works fine and also uses GATT for provisioning and configuration. Meshctl provisions fine, but hangs on discovery for the configuration service. I think the problem is with meshctl's discovery filter. I'm not familiar enough with the filter stuff to understand what's going on. While meshctl is hanging on discovery, if I scan with bluetoothctl and connect to the node, the callback in meshctl fires and it does a get- composition and proceeds normally. That's all the detail I've got. Steve
|
|
Steve Brown
Hi Johan,
Some more detail. On Wed, 2018-04-18 at 16:30 -0600, Steve Brown wrote: Hi Johan,I added some instrumentation to parse_service_data and parse_mesh_service_data. The data type that gets passed to parse_mesh_service_data in data[0] is 0x00 while the function is expecting 0x01 (CONN_TYPE_IDENTITY), the value of connection.type. That test fails and the function returns false. No connection is made to the node. Device property changed ServiceData update_device_info called parse_service_data target 00001827-0000-1000-8000-00805f9b34fb parse_service_data failed parse_service_data target 00001828-0000-1000-8000-00805f9b34fb parse_service_data : parse_mesh_service_data parse_mesh_service_data data[0]:0x00 discovering:0x01 cnx.type:0x01 Does BT_MESH_NODE_IDENTITY_STOPPED get passed as the connection type? Steve
|
|