Hi Vikrant,

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 !!

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

Hi Vikrant,

On Wed, 2018-04-18 at 07:06 -0600, Steve Brown wrote:

Hi Vikrant,

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/R
EA
DME.html

But able to provision it using Silicon Labs Bluetooth Mesh App.

Is it bug from meshctl (BlueZ) side ?

Thank You !!

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

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 commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV

Do you have more details on this? Is there a bug with the patch, or just
something else that needs to be tuned somewhere?

Johan

Hi Johan,

On Wed, 2018-04-18 at 11:32 -0700, Johan Hedberg wrote:

Hi Steve,

On Wed, Apr 18, 2018, Steve Brown wrote:

I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV

Do you have more details on this? Is there a bug with the patch, or
just
something else that needs to be tuned somewhere?

Johan

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

Hi Johan,

Some more detail.

On Wed, 2018-04-18 at 16:30 -0600, Steve Brown wrote:

Hi Johan,

On Wed, 2018-04-18 at 11:32 -0700, Johan Hedberg wrote:

Hi Steve,

On Wed, Apr 18, 2018, Steve Brown wrote:

I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV

Do you have more details on this? Is there a bug with the patch, or
just
something else that needs to be tuned somewhere?

Johan

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

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