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,[email protected]
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
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
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 <[email protected]>
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.
Hi Steve,
That specific patch doesn't change the meshctl, the following one does:
commit d6eec1b67d6d9e3336b7e3cd8f655baf408d864a
Author: Luiz Augusto von Dentz <[email protected]>
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 <[email protected]> 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 <[email protected]>
> 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.
>
>
>
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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> > 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,
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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> > 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.
> >
> >
> >
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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> > 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.
> >
> >
> >
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 <[email protected]>
>> 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 <[email protected]> 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 <[email protected]>
>>> 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.
>>>
>>>
>>>
>
Hi Steve,
Let me know when you have a patch.
On Thu, May 16, 2019 at 9:15 AM Shaik Mahaboob Nazeer
<[email protected]> 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 <[email protected]>
> >> 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 <[email protected]> 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 <[email protected]>
> >>> 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