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