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:
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
On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:
Hi,I looked at this too. Provisioning seems to complete, but the proxy
I am not able to provision my Devices which is executing sample
example at
$/zephyr/samples/boards/nrf52/mesh/onoff-app/
http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/REA
DME.html
But able to provision it using Silicon Labs Bluetooth Mesh App.
Is it bug from meshctl (BlueZ) side ?
Thank You !!
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,
I looked at this too. Provisioning seems to complete, but the proxy
On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:
> Hi,
>
> I am not able to provision my Devices which is executing sample
> example at
> $/zephyr/samples/boards/nrf52/mesh/onoff-app/
>
> http://docs.zephyrproject.org/samples/boards/nrf52/mesh/ onoff-app/REA
> DME.html
>
> But able to provision it using Silicon Labs Bluetooth Mesh App.
>
> Is it bug from meshctl (BlueZ) side ?
>
> Thank You !!
>
>
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
Steve Brown
Hi Vikrant,
On Wed, 2018-04-18 at 07:06 -0600, Steve Brown wrote:
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
Steve
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
On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:Hi,I looked at this too. Provisioning seems to complete, but the proxy
I am not able to provision my Devices which is executing sample
example at
$/zephyr/samples/boards/nrf52/mesh/onoff-app/
http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/R
EA
DME.html
But able to provision it using Silicon Labs Bluetooth Mesh App.
Is it bug from meshctl (BlueZ) side ?
Thank You !!
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
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
Steve
Hi Steve,
On Wed, Apr 18, 2018, Steve Brown wrote:
something else that needs to be tuned somewhere?
Johan
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
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
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:
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
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
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
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
just
something else that needs to be tuned somewhere?
Johan
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:
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
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
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
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
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
just
something else that needs to be tuned somewhere?
Johan
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
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