* Re: Issue with mesh provisioning.
2019-05-15 10:48 ` Von Dentz, Luiz
@ 2019-05-15 11:20 ` Steve Brown
2019-05-15 11:55 ` Steve Brown
2019-05-15 12:12 ` Steve Brown
2 siblings, 0 replies; 9+ messages in thread
From: Steve Brown @ 2019-05-15 11:20 UTC (permalink / raw)
To: Von Dentz, Luiz; +Cc: Shaik Mahaboob Nazeer, linux-bluetooth, Jonas Remmert
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.
> >
> >
> >
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Issue with mesh provisioning.
2019-05-15 10:48 ` Von Dentz, Luiz
2019-05-15 11:20 ` Steve Brown
@ 2019-05-15 11:55 ` Steve Brown
2019-05-15 12:12 ` Steve Brown
2 siblings, 0 replies; 9+ messages in thread
From: Steve Brown @ 2019-05-15 11:55 UTC (permalink / raw)
To: Von Dentz, Luiz; +Cc: Shaik Mahaboob Nazeer, linux-bluetooth, Jonas Remmert
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.
> >
> >
> >
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Issue with mesh provisioning.
2019-05-15 10:48 ` Von Dentz, Luiz
2019-05-15 11:20 ` Steve Brown
2019-05-15 11:55 ` Steve Brown
@ 2019-05-15 12:12 ` Steve Brown
2019-05-16 6:12 ` Shaik Mahaboob Nazeer
2 siblings, 1 reply; 9+ messages in thread
From: Steve Brown @ 2019-05-15 12:12 UTC (permalink / raw)
To: Von Dentz, Luiz; +Cc: Shaik Mahaboob Nazeer, linux-bluetooth, Jonas Remmert
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.
> >
> >
> >
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: Issue with mesh provisioning.
2019-05-15 12:12 ` Steve Brown
@ 2019-05-16 6:12 ` Shaik Mahaboob Nazeer
2019-05-16 7:32 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 9+ messages in thread
From: Shaik Mahaboob Nazeer @ 2019-05-16 6:12 UTC (permalink / raw)
To: Steve Brown, Von Dentz, Luiz; +Cc: linux-bluetooth, Jonas Remmert
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.
>>>
>>>
>>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Issue with mesh provisioning.
2019-05-16 6:12 ` Shaik Mahaboob Nazeer
@ 2019-05-16 7:32 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 9+ messages in thread
From: Luiz Augusto von Dentz @ 2019-05-16 7:32 UTC (permalink / raw)
To: Shaik Mahaboob Nazeer
Cc: Steve Brown, Von Dentz, Luiz, linux-bluetooth, Jonas Remmert
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
^ permalink raw reply [flat|nested] 9+ messages in thread