Some more detail.
On Wed, 2018-04-18 at 16:30 -0600, Steve Brown wrote:
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
Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
something else that needs to be tuned somewhere?
the SILABS App works fine and also uses GATT for provisioning and
configuration. Meshctl provisions fine, but hangs on discovery for
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
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.
I added some instrumentation to parse_service_data and
The data type that gets passed to parse_mesh_service_data in data 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
parse_service_data target 00001827-0000-1000-8000-00805f9b34fb
parse_service_data target 00001828-0000-1000-8000-00805f9b34fb
parse_service_data : parse_mesh_service_data
parse_mesh_service_data data:0x00 discovering:0x01 cnx.type:0x01
Does BT_MESH_NODE_IDENTITY_STOPPED get passed as the connection type?