Issue with mesh provisioning.

Issue with mesh provisioning.

[Shaik Mahaboob Nazeer]

hi,

-> We tried Zephyr Mesh onoff example on nrf52 eval kit to test the Mesh Functionality.For provisioning of the node
   we are using meshctl, built from the latest current master of the bluez source.So during the provisioning of the node when we
   start the "meshctl" and run the "discover-unprovisioned on" we are able to get the Device UUID for the provisioning.

   Later when we try to provision the node using the "provision <UUID>" command it initiate the provision and does not wait
   for the user to enter OOB .You can find the log as below.
   /*******************************************/
   $meshctl
   Waiting to connect to bluetoothd...Reading prov_db.json and local_node.json
   from /home/nazeer/.config/meshctl directory
   [meshctl]# discover-unprovisioned on
   SetDiscoveryFilter success
   Discovery started
   Adapter property changed
   [CHG] Controller 00:1B:DC:06:96:17 Discovering: yes
             Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
             Device UUID: 81f5d3bd49fa00000000000000000000
             OOB: 0000
   [meshctl]# provision 81f5d3bd49fa00000000000000000000
   Trying to connect Device FA:49:BD:D3:F5:81 Zephyr
   Adapter property changed
   [CHG] Controller 00:1B:DC:06:96:17 Discovering: no
   Connection successful 
   Services resolved yes
   Found matching char: path
   /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0011, uuid
   00002adb-0000-1000-8000-00805f9b34fb
   Found matching char: path
   /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013, uuid
   00002adc-0000-1000-8000-00805f9b34fb
   Start notification on
   /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013
   Characteristic property changed
   /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013
   AcquireNotify success: fd 7 MTU 69
   Notify for Mesh Provisioning Out Data started
   Open-Node: 0x55aca5ac1220
   Open-Prov: 0x55aca5abfb40
   Open-Prov: proxy 0x55aca5ac3d10
   Initiated provisioning
   Characteristic property changed
   /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0011
   AcquireWrite success: fd 8 MTU 69
   GATT-TX:     03 00 10
   GATT-RX:     03 01 04 00 01 00 00 06 00 18 00 00 00
   Got provisioning data (12 bytes)
                01 04 00 01 00 00 06 00 18 00 00 00
   GATT-TX:     03 02 00 00 02 04 06
   GATT-TX:     03 03 76 4a b7 61 52 e1 72 9c b0 cc 95 ad 62 22
   GATT-TX:     8b 65 8f 2a dd 2c 79 a0 ec 5e 8e db a5 65 1b 76
   GATT-TX:     dd cf 63 4d 17 aa a0 a4 ea d4 5e 17 2e a6 18 8e
   GATT-TX:     19 83 56 97 cd c9 81 50 15 ff 47 37 de 92 3a 80
   GATT-TX:     30 64
   [Zephyr]#
  /********************************************/

-> Later we tried to remove the OOB security from the zephyr onoff code and tried to do provisioning again,linux-bluetooth@vger.kernel.org 
   but this time it completely fails to start provisioning.Please find the log as below
  /**********************************/
  meshctl]# provision 81f5d3bd49fa00000000000000000000
  Trying to connect Device FA:49:BD:D3:F5:81 Zephyr
  Adapter property changed
  [CHG] Controller 00:1B:DC:06:96:17 Discovering: no
  Connection successful
  Services resolved yes
  Found matching char: path
  /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0011, uuid
  00002adb-0000-1000-8000-00805f9b34fb
  Found matching char: path
  /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013, uuid
  00002adc-0000-1000-8000-00805f9b34fb
  Start notification on
  /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013
  Characteristic property changed
  /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013
  AcquireNotify success: fd 7 MTU 69
  Notify for Mesh Provisioning Out Data started
  Failed to start provisioning
  Attempting to disconnect from FA:49:BD:D3:F5:81
  Characteristic property changed
  /org/bluez/hci0/dev_FA_49_BD_D3_F5_81/service0010/char0013
  Services resolved no
  [meshctl]#
  /**************************************/

Could you elaborate a little on the status of the current master of bluez in regards to BLE mesh, is it usable or should we look to older versions?

Do you know if there is a common issue while provisioning of the node with the current master and
is there anything that need to be configured before provisioning? 

-- 
Thanks and Regards

Re: Issue with mesh provisioning.

[Steve Brown]

On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> hi,
> 
> -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test the
> Mesh Functionality.For provisioning of the node
>    we are using meshctl, built from the latest current master of the
> bluez source.So during the provisioning of the node when we
>    start the "meshctl" and run the "discover-unprovisioned on" we are
> able to get the Device UUID for the provisioning.
> 
>    Later when we try to provision the node using the "provision
> <UUID>" command it initiate the provision and does not wait
>    for the user to enter OOB .You can find the log as below.
>    /*******************************************/
> 

--- snip ---

>   /**************************************/
> 
> Could you elaborate a little on the status of the current master of
> bluez in regards to BLE mesh, is it usable or should we look to older
> versions?
> 
> Do you know if there is a common issue while provisioning of the node
> with the current master and
> is there anything that need to be configured before provisioning? 
> 
I get the same results.

I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a

That was the last time I used meshctl.

It requests an oob string and completes provisioning.

Steve

Re: Issue with mesh provisioning.

[Steve Brown]

On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> > hi,
> > 
> > -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test the
> > Mesh Functionality.For provisioning of the node
> >    we are using meshctl, built from the latest current master of
> > the
> > bluez source.So during the provisioning of the node when we
> >    start the "meshctl" and run the "discover-unprovisioned on" we
> > are
> > able to get the Device UUID for the provisioning.
> > 
> >    Later when we try to provision the node using the "provision
> > <UUID>" command it initiate the provision and does not wait
> >    for the user to enter OOB .You can find the log as below.
> >    /*******************************************/
> > 
> 
> --- snip ---
> 
> >   /**************************************/
> > 
> > Could you elaborate a little on the status of the current master of
> > bluez in regards to BLE mesh, is it usable or should we look to
> > older
> > versions?
> > 
> > Do you know if there is a common issue while provisioning of the
> > node
> > with the current master and
> > is there anything that need to be configured before provisioning? 
> > 
> I get the same results.
> 
> I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> 
> That was the last time I used meshctl.
> 
> It requests an oob string and completes provisioning.
> 
> Steve
> 

I bisected to 

commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Nov 19 15:36:15 2018 +0200

    client: Switch from write to sendmsg for Acquire*
    
    Use sendmsg with MSG_NOSIGNAL to prevent crashes involving SIGPIPE.

Re: Issue with mesh provisioning.

[Von Dentz, Luiz]

Hi Steve,

That specific patch doesn't change the meshctl, the following one does:

commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Nov 19 17:35:54 2018 +0200

    meshctl: Switch from write to sendmsg for Acquire*

    Use sendmsg with MSG_NOSIGNAL to prevent crashes involving SIGPIPE.

Not sure what is the problem with that since we just switch from a
pipe to a socketpair.

On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
>
> On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> > On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> > > hi,
> > >
> > > -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test the
> > > Mesh Functionality.For provisioning of the node
> > >    we are using meshctl, built from the latest current master of
> > > the
> > > bluez source.So during the provisioning of the node when we
> > >    start the "meshctl" and run the "discover-unprovisioned on" we
> > > are
> > > able to get the Device UUID for the provisioning.
> > >
> > >    Later when we try to provision the node using the "provision
> > > <UUID>" command it initiate the provision and does not wait
> > >    for the user to enter OOB .You can find the log as below.
> > >    /*******************************************/
> > >
> >
> > --- snip ---
> >
> > >   /**************************************/
> > >
> > > Could you elaborate a little on the status of the current master of
> > > bluez in regards to BLE mesh, is it usable or should we look to
> > > older
> > > versions?
> > >
> > > Do you know if there is a common issue while provisioning of the
> > > node
> > > with the current master and
> > > is there anything that need to be configured before provisioning?
> > >
> > I get the same results.
> >
> > I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> >
> > That was the last time I used meshctl.
> >
> > It requests an oob string and completes provisioning.
> >
> > Steve
> >
>
> I bisected to
>
> commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Date:   Mon Nov 19 15:36:15 2018 +0200
>
>     client: Switch from write to sendmsg for Acquire*
>
>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving SIGPIPE.
>
>
>

Re: Issue with mesh provisioning.

[Steve Brown]

Hi Luiz,

My bad. I misinterpreted the bisect. It's the following commit.

d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
meshctl: Switch from write to sendmsg for Acquire*



On Wed, 2019-05-15 at 13:48 +0300, Von Dentz, Luiz wrote:
> Hi Steve,
> 
> That specific patch doesn't change the meshctl, the following one
> does:
> 
> commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Date:   Mon Nov 19 17:35:54 2018 +0200
> 
>     meshctl: Switch from write to sendmsg for Acquire*
> 
>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> SIGPIPE.
> 
> Not sure what is the problem with that since we just switch from a
> pipe to a socketpair.
> 
> On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
> > On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> > > On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> > > > hi,
> > > > 
> > > > -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test
> > > > the
> > > > Mesh Functionality.For provisioning of the node
> > > >    we are using meshctl, built from the latest current master
> > > > of
> > > > the
> > > > bluez source.So during the provisioning of the node when we
> > > >    start the "meshctl" and run the "discover-unprovisioned on"
> > > > we
> > > > are
> > > > able to get the Device UUID for the provisioning.
> > > > 
> > > >    Later when we try to provision the node using the "provision
> > > > <UUID>" command it initiate the provision and does not wait
> > > >    for the user to enter OOB .You can find the log as below.
> > > >    /*******************************************/
> > > > 
> > > 
> > > --- snip ---
> > > 
> > > >   /**************************************/
> > > > 
> > > > Could you elaborate a little on the status of the current
> > > > master of
> > > > bluez in regards to BLE mesh, is it usable or should we look to
> > > > older
> > > > versions?
> > > > 
> > > > Do you know if there is a common issue while provisioning of
> > > > the
> > > > node
> > > > with the current master and
> > > > is there anything that need to be configured before
> > > > provisioning?
> > > > 
> > > I get the same results.
> > > 
> > > I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> > > 
> > > That was the last time I used meshctl.
> > > 
> > > It requests an oob string and completes provisioning.
> > > 
> > > Steve
> > > 
> > 
> > I bisected to
> > 
> > commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
> > Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > Date:   Mon Nov 19 15:36:15 2018 +0200
> > 
> >     client: Switch from write to sendmsg for Acquire*
> > 
> >     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> > SIGPIPE.
> > 
> > 
> > 

Re: Issue with mesh provisioning.

[Steve Brown]

Luiz,

Some more:

The recvmsg call at tools/mesh/gatt.c:417 returns -1 and
errno 11 "Resource temporarily unavailable"

The log follows. The first read succeeded, but the second fails.

======================

[CHG] Controller 00:1A:7D:DA:71:14 Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_D0_09_F0_18_BF_38/service0010/char0011, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_D0_09_F0_18_BF_38/service0010/char0013, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_D0_09_F0_18_BF_38/service0010/char0013
Characteristic property changed /org/bluez/hci0/dev_D0_09_F0_18_BF_38/service0010/char0013
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x555776243190
Open-Prov: 0x555776234250
Open-Prov: proxy 0x55577623f3f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_D0_09_F0_18_BF_38/service0010/char0011
AcquireWrite success: fd 8 MTU 69
GATT-TX:	 03 00 10 
sock_read len: 13
GATT-RX:	 03 01 04 00 01 00 00 06 00 18 00 00 00 
sock_read len_sar: 13
Got provisioning data (12 bytes)
	 01 04 00 01 00 00 06 00 18 00 00 00 
GATT-TX:	 03 02 00 00 02 04 06 
GATT-TX:	 03 03 e4 ae 6e 5e fc b7 b9 63 74 f0 ca 71 89 c4 
GATT-TX:	 af 00 a2 fd f8 74 1d fd 87 74 8a 86 20 91 bd ed 
GATT-TX:	 54 87 6b 63 5d ec 42 1f 19 fb 1a c9 05 88 b0 be 
GATT-TX:	 91 80 97 ce c4 f3 b0 79 72 12 e9 bb 81 a2 8e ed 
GATT-TX:	 a5 6b 
sock_read len: -1
sock_read error 11 Resource temporarily unavailable[Zephyr]# quit

=================

On Wed, 2019-05-15 at 13:48 +0300, Von Dentz, Luiz wrote:
> Hi Steve,
> 
> That specific patch doesn't change the meshctl, the following one
> does:
> 
> commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Date:   Mon Nov 19 17:35:54 2018 +0200
> 
>     meshctl: Switch from write to sendmsg for Acquire*
> 
>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> SIGPIPE.
> 
> Not sure what is the problem with that since we just switch from a
> pipe to a socketpair.
> 
> On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
> > On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> > > On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> > > > hi,
> > > > 
> > > > -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test
> > > > the
> > > > Mesh Functionality.For provisioning of the node
> > > >    we are using meshctl, built from the latest current master
> > > > of
> > > > the
> > > > bluez source.So during the provisioning of the node when we
> > > >    start the "meshctl" and run the "discover-unprovisioned on"
> > > > we
> > > > are
> > > > able to get the Device UUID for the provisioning.
> > > > 
> > > >    Later when we try to provision the node using the "provision
> > > > <UUID>" command it initiate the provision and does not wait
> > > >    for the user to enter OOB .You can find the log as below.
> > > >    /*******************************************/
> > > > 
> > > 
> > > --- snip ---
> > > 
> > > >   /**************************************/
> > > > 
> > > > Could you elaborate a little on the status of the current
> > > > master of
> > > > bluez in regards to BLE mesh, is it usable or should we look to
> > > > older
> > > > versions?
> > > > 
> > > > Do you know if there is a common issue while provisioning of
> > > > the
> > > > node
> > > > with the current master and
> > > > is there anything that need to be configured before
> > > > provisioning?
> > > > 
> > > I get the same results.
> > > 
> > > I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> > > 
> > > That was the last time I used meshctl.
> > > 
> > > It requests an oob string and completes provisioning.
> > > 
> > > Steve
> > > 
> > 
> > I bisected to
> > 
> > commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
> > Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > Date:   Mon Nov 19 15:36:15 2018 +0200
> > 
> >     client: Switch from write to sendmsg for Acquire*
> > 
> >     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> > SIGPIPE.
> > 
> > 
> > 

Re: Issue with mesh provisioning.

[Steve Brown]

Hi Luiz,

Would this be an appropriate fix.

It seems to solve the problem.

diff --git a/tools/mesh/gatt.c b/tools/mesh/gatt.c
index 2269a20cf..0a942d4eb 100644
--- a/tools/mesh/gatt.c
+++ b/tools/mesh/gatt.c
@@ -415,8 +415,11 @@ static bool sock_read(struct io *io, bool prov, void *user_data)
 	msg.msg_iovlen = 1;
 
 	while ((len = recvmsg(fd, &msg, MSG_DONTWAIT))) {
-		if (len <= 0)
+		if (len <= 0) {
+			if (errno == EAGAIN)
+				break;
 			return false;
+		}
 
 		res = buf;
 		len_sar = mesh_gatt_sar(&res, len);

If so, I'll submit a patch.

Steve

On Wed, 2019-05-15 at 13:48 +0300, Von Dentz, Luiz wrote:
> Hi Steve,
> 
> That specific patch doesn't change the meshctl, the following one
> does:
> 
> commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Date:   Mon Nov 19 17:35:54 2018 +0200
> 
>     meshctl: Switch from write to sendmsg for Acquire*
> 
>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> SIGPIPE.
> 
> Not sure what is the problem with that since we just switch from a
> pipe to a socketpair.
> 
> On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
> > On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> > > On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> > > > hi,
> > > > 
> > > > -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test
> > > > the
> > > > Mesh Functionality.For provisioning of the node
> > > >    we are using meshctl, built from the latest current master
> > > > of
> > > > the
> > > > bluez source.So during the provisioning of the node when we
> > > >    start the "meshctl" and run the "discover-unprovisioned on"
> > > > we
> > > > are
> > > > able to get the Device UUID for the provisioning.
> > > > 
> > > >    Later when we try to provision the node using the "provision
> > > > <UUID>" command it initiate the provision and does not wait
> > > >    for the user to enter OOB .You can find the log as below.
> > > >    /*******************************************/
> > > > 
> > > 
> > > --- snip ---
> > > 
> > > >   /**************************************/
> > > > 
> > > > Could you elaborate a little on the status of the current
> > > > master of
> > > > bluez in regards to BLE mesh, is it usable or should we look to
> > > > older
> > > > versions?
> > > > 
> > > > Do you know if there is a common issue while provisioning of
> > > > the
> > > > node
> > > > with the current master and
> > > > is there anything that need to be configured before
> > > > provisioning?
> > > > 
> > > I get the same results.
> > > 
> > > I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> > > 
> > > That was the last time I used meshctl.
> > > 
> > > It requests an oob string and completes provisioning.
> > > 
> > > Steve
> > > 
> > 
> > I bisected to
> > 
> > commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
> > Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > Date:   Mon Nov 19 15:36:15 2018 +0200
> > 
> >     client: Switch from write to sendmsg for Acquire*
> > 
> >     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> > SIGPIPE.
> > 
> > 
> > 

Re: Issue with mesh provisioning.

[Shaik Mahaboob Nazeer]

hi Steve,

Yes with this changes it is working as expected. 

Best Regards.

On 15/05/19 17:42, Steve Brown wrote:
> Hi Luiz,
> 
> Would this be an appropriate fix.
> 
> It seems to solve the problem.
> 
> diff --git a/tools/mesh/gatt.c b/tools/mesh/gatt.c
> index 2269a20cf..0a942d4eb 100644
> --- a/tools/mesh/gatt.c
> +++ b/tools/mesh/gatt.c
> @@ -415,8 +415,11 @@ static bool sock_read(struct io *io, bool prov, void *user_data)
>  	msg.msg_iovlen = 1;
>  
>  	while ((len = recvmsg(fd, &msg, MSG_DONTWAIT))) {
> -		if (len <= 0)
> +		if (len <= 0) {
> +			if (errno == EAGAIN)
> +				break;
>  			return false;
> +		}
>  
>  		res = buf;
>  		len_sar = mesh_gatt_sar(&res, len);
> 
> If so, I'll submit a patch.
> 
> Steve
> 
> On Wed, 2019-05-15 at 13:48 +0300, Von Dentz, Luiz wrote:
>> Hi Steve,
>>
>> That specific patch doesn't change the meshctl, the following one
>> does:
>>
>> commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
>> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>> Date:   Mon Nov 19 17:35:54 2018 +0200
>>
>>     meshctl: Switch from write to sendmsg for Acquire*
>>
>>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
>> SIGPIPE.
>>
>> Not sure what is the problem with that since we just switch from a
>> pipe to a socketpair.
>>
>> On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
>>> On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
>>>> On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
>>>>> hi,
>>>>>
>>>>> -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test
>>>>> the
>>>>> Mesh Functionality.For provisioning of the node
>>>>>    we are using meshctl, built from the latest current master
>>>>> of
>>>>> the
>>>>> bluez source.So during the provisioning of the node when we
>>>>>    start the "meshctl" and run the "discover-unprovisioned on"
>>>>> we
>>>>> are
>>>>> able to get the Device UUID for the provisioning.
>>>>>
>>>>>    Later when we try to provision the node using the "provision
>>>>> <UUID>" command it initiate the provision and does not wait
>>>>>    for the user to enter OOB .You can find the log as below.
>>>>>    /*******************************************/
>>>>>
>>>>
>>>> --- snip ---
>>>>
>>>>>   /**************************************/
>>>>>
>>>>> Could you elaborate a little on the status of the current
>>>>> master of
>>>>> bluez in regards to BLE mesh, is it usable or should we look to
>>>>> older
>>>>> versions?
>>>>>
>>>>> Do you know if there is a common issue while provisioning of
>>>>> the
>>>>> node
>>>>> with the current master and
>>>>> is there anything that need to be configured before
>>>>> provisioning?
>>>>>
>>>> I get the same results.
>>>>
>>>> I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
>>>>
>>>> That was the last time I used meshctl.
>>>>
>>>> It requests an oob string and completes provisioning.
>>>>
>>>> Steve
>>>>
>>>
>>> I bisected to
>>>
>>> commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
>>> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>>> Date:   Mon Nov 19 15:36:15 2018 +0200
>>>
>>>     client: Switch from write to sendmsg for Acquire*
>>>
>>>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
>>> SIGPIPE.
>>>
>>>
>>>
> 
 

Re: Issue with mesh provisioning.

[Luiz Augusto von Dentz]

Hi Steve,

Let me know when you have a patch.

On Thu, May 16, 2019 at 9:15 AM Shaik Mahaboob Nazeer
<nazeer.m@phytec.in> wrote:
>
> hi Steve,
>
> Yes with this changes it is working as expected.
>
> Best Regards.
>
> On 15/05/19 17:42, Steve Brown wrote:
> > Hi Luiz,
> >
> > Would this be an appropriate fix.
> >
> > It seems to solve the problem.
> >
> > diff --git a/tools/mesh/gatt.c b/tools/mesh/gatt.c
> > index 2269a20cf..0a942d4eb 100644
> > --- a/tools/mesh/gatt.c
> > +++ b/tools/mesh/gatt.c
> > @@ -415,8 +415,11 @@ static bool sock_read(struct io *io, bool prov, void *user_data)
> >       msg.msg_iovlen = 1;
> >
> >       while ((len = recvmsg(fd, &msg, MSG_DONTWAIT))) {
> > -             if (len <= 0)
> > +             if (len <= 0) {
> > +                     if (errno == EAGAIN)
> > +                             break;
> >                       return false;
> > +             }
> >
> >               res = buf;
> >               len_sar = mesh_gatt_sar(&res, len);
> >
> > If so, I'll submit a patch.
> >
> > Steve
> >
> > On Wed, 2019-05-15 at 13:48 +0300, Von Dentz, Luiz wrote:
> >> Hi Steve,
> >>
> >> That specific patch doesn't change the meshctl, the following one
> >> does:
> >>
> >> commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
> >> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> >> Date:   Mon Nov 19 17:35:54 2018 +0200
> >>
> >>     meshctl: Switch from write to sendmsg for Acquire*
> >>
> >>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> >> SIGPIPE.
> >>
> >> Not sure what is the problem with that since we just switch from a
> >> pipe to a socketpair.
> >>
> >> On Wed, May 15, 2019 at 1:01 PM Steve Brown <sbrown@ewol.com> wrote:
> >>> On Tue, 2019-05-14 at 15:25 -0400, Steve Brown wrote:
> >>>> On Tue, 2019-05-14 at 14:50 +0530, Shaik Mahaboob Nazeer wrote:
> >>>>> hi,
> >>>>>
> >>>>> -> We tried Zephyr Mesh onoff example on nrf52 eval kit to test
> >>>>> the
> >>>>> Mesh Functionality.For provisioning of the node
> >>>>>    we are using meshctl, built from the latest current master
> >>>>> of
> >>>>> the
> >>>>> bluez source.So during the provisioning of the node when we
> >>>>>    start the "meshctl" and run the "discover-unprovisioned on"
> >>>>> we
> >>>>> are
> >>>>> able to get the Device UUID for the provisioning.
> >>>>>
> >>>>>    Later when we try to provision the node using the "provision
> >>>>> <UUID>" command it initiate the provision and does not wait
> >>>>>    for the user to enter OOB .You can find the log as below.
> >>>>>    /*******************************************/
> >>>>>
> >>>>
> >>>> --- snip ---
> >>>>
> >>>>>   /**************************************/
> >>>>>
> >>>>> Could you elaborate a little on the status of the current
> >>>>> master of
> >>>>> bluez in regards to BLE mesh, is it usable or should we look to
> >>>>> older
> >>>>> versions?
> >>>>>
> >>>>> Do you know if there is a common issue while provisioning of
> >>>>> the
> >>>>> node
> >>>>> with the current master and
> >>>>> is there anything that need to be configured before
> >>>>> provisioning?
> >>>>>
> >>>> I get the same results.
> >>>>
> >>>> I check out 48a2c3db1ccff28a615fac56066ca7d721f98d0a
> >>>>
> >>>> That was the last time I used meshctl.
> >>>>
> >>>> It requests an oob string and completes provisioning.
> >>>>
> >>>> Steve
> >>>>
> >>>
> >>> I bisected to
> >>>
> >>> commit 91df85690cc1943e46ef90561dd1ac0d673ee3d7
> >>> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> >>> Date:   Mon Nov 19 15:36:15 2018 +0200
> >>>
> >>>     client: Switch from write to sendmsg for Acquire*
> >>>
> >>>     Use sendmsg with MSG_NOSIGNAL to prevent crashes involving
> >>> SIGPIPE.
> >>>
> >>>
> >>>
> >
>
>


-- 
Luiz Augusto von Dentz