Date   

Re: [Zephyr-users] Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto
 

Vikrant,
answering inline. 

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Ok.
 
Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

I really need that.
 
Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Do you need help on that? I am a little bit confusing. 
I was willing to create the sample related to OTA and mesh. But if there is other sample as you said related to mesh, it would be a pleasure to help.

Is there any thing I can do?

Best regards,
Rodrigo Peixoto.


Re: [Zephyr-users] Device Firmware Update + Zephyr + #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Rodrigo,

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Regards,
Vikrant

On Fri, Apr 27, 2018, 7:44 PM Rodrigo Peixoto <rodrigopex@...> wrote:

Hi vikrant.

I could do the integration! Now the SMP_Server sample is integrated to the mesh one. I need to play a little more with it. I have already tested the mcumgr a lot, but not too much the mesh one after the integration. I am considering the possibility of creating a sample with the integrated code.

What do you think? Necessary?

Best regards, Rodrigo Peixoto.


Extending Error Codes

laczenJMS
 

Hello Zephyr Developers,

I recently had a request to change the error codes in a zephyr module
to use the standard supplied error codes. Doing so would reduce the
descriptiveness of the error codes so I did not really like this.
However in my module I was using error codes (-) 1 to 10, and I think
this was a bad idea. If someone needs to check the error code he/she
might end up looking at errno.h and finding a completely different
definition.

Would it not be a good idea to allow extending the standard error
codes with module (subsystem) specific error codes that can be as
descriptive as required by allowing modules to use error codes above a
specific value. E.g. any module can use it's own error codes starting
from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap
between standard errors and "user" errors.

What's your opinion ?

Kind regards,

Jehudi


Re: Shave Zephyr boards with Occam's razor

Erwan Gouriou
 

Good! Thanks Carles.

On 27 April 2018 at 14:53, Cufi, Carles <Carles.Cufi@...> wrote:

In case anyone is wondering, the current dtc version in our Windows packaging scheme is 1.4.4, so we should be safe in this regard.

 

From: devel@... <devel@...> On Behalf Of Erwan Gouriou
Sent: 27 April 2018 14:35
To: Marti Bolivar <marti@...>
Cc: Bøe, Sebastian <Sebastian.Boe@...>; zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Shave Zephyr boards with Occam's razor

 

Hi all,

Guidelines for default board configuration are now documented in Zephyr board porting guide.

Next step will be to get all existing boards to comply with these guidelines.

I've open issue #7191: boards: Move existing boards to "default configuration guidelines"[0] to drive this.

PR #7176[1] has also been created to provide a reference for board configuration, comments are welcome.

Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors

in device tree files requires usage of dtc > v1.4.1 [3].

Erwan

 

 

On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:

For those interested in board shaving: https://github.com/zephyrproject-rtos/zephyr/issues/6858

 

On 29 March 2018 at 17:04, Erwan Gouriou <erwan.gouriou@...> wrote:

Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress

 

On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:

 

On Wed, Mar 28, 2018, 8:02 AM Erwan Gouriou <erwan.gouriou@...> wrote:

 

 

On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:

Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"

 

Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

So that enabling (activation) is application responsibility.

 

With this modification, I think this list sounds great for users (and should make things more consistent and simple for developers and reviewers too).

 

Thanks a lot, Erwan, for driving this.

 

Marti

 

 

I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor


TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017

 

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 



Re: Shave Zephyr boards with Occam's razor

Carles Cufi
 

In case anyone is wondering, the current dtc version in our Windows packaging scheme is 1.4.4, so we should be safe in this regard.

 

From: devel@... <devel@...> On Behalf Of Erwan Gouriou
Sent: 27 April 2018 14:35
To: Marti Bolivar <marti@...>
Cc: Bøe, Sebastian <Sebastian.Boe@...>; zephyr-devel <zephyr-devel@...>
Subject: Re: [Zephyr-devel] Shave Zephyr boards with Occam's razor

 

Hi all,

Guidelines for default board configuration are now documented in Zephyr board porting guide.

Next step will be to get all existing boards to comply with these guidelines.

I've open issue #7191: boards: Move existing boards to "default configuration guidelines"[0] to drive this.

PR #7176[1] has also been created to provide a reference for board configuration, comments are welcome.

Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors

in device tree files requires usage of dtc > v1.4.1 [3].

Erwan

 

 

On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:

For those interested in board shaving: https://github.com/zephyrproject-rtos/zephyr/issues/6858

 

On 29 March 2018 at 17:04, Erwan Gouriou <erwan.gouriou@...> wrote:

Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress

 

On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:

 

On Wed, Mar 28, 2018, 8:02 AM Erwan Gouriou <erwan.gouriou@...> wrote:

 

 

On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:

Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"

 

Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

So that enabling (activation) is application responsibility.

 

With this modification, I think this list sounds great for users (and should make things more consistent and simple for developers and reviewers too).

 

Thanks a lot, Erwan, for driving this.

 

Marti

 

 

I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor


TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017

 

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 


Re: Shave Zephyr boards with Occam's razor

Erwan Gouriou
 

Hi all,

Guidelines for default board configuration are now documented in Zephyr board porting guide.
Next step will be to get all existing boards to comply with these guidelines.

I've open issue #7191: boards: Move existing boards to "default configuration guidelines"[0] to drive this.
PR #7176[1] has also been created to provide a reference for board configuration, comments are welcome.

Please note that this activity has a dependency on upcoming SDK v0.9.3, as introduction of connectors
in device tree files requires usage of dtc > v1.4.1 [3].


Erwan


On 29 March 2018 at 17:14, Erwan Gouriou <erwan.gouriou@...> wrote:
For those interested in board shaving: https://github.com/zephyrproject-rtos/zephyr/issues/6858

On 29 March 2018 at 17:04, Erwan Gouriou <erwan.gouriou@...> wrote:
Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress

On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:


On Wed, Mar 28, 2018, 8:02 AM Erwan Gouriou <erwan.gouriou@...> wrote:


On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:
Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"


Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"


So that enabling (activation) is application responsibility.

With this modification, I think this list sounds great for users (and should make things more consistent and simple for developers and reviewers too).

Thanks a lot, Erwan, for driving this.

Marti


I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@...hyrproject.org <zephyr-devel-bounces@...phyrproject.org> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor

TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




Re: [Zephyr-tsc] Examples for "Zstream" Socket/TLS API

Paul Sokolovsky
 

Hello Patrik,

On Fri, 27 Apr 2018 09:37:23 +0000
"Flykt, Patrik" <patrik.flykt@intel.com> wrote:

Hi,

On Thu, 2018-04-26 at 22:43 +0300, Paul Sokolovsky wrote:
I would like to propose to Patrik, the author of the alternative
proposal, to take the "big_http_download" socket sample as the
baseline for API comparison (followed by the other 4 in-tree samples
if there're enough resources). I also would like to draw attention
to showing portability of a TLS application to other POSIX/BSD
Sockets OSes.
I looked through the socket based samples in the Zephyr source code
and for the sake of presenting the various API options, I think we
should go with something very close to the http_get/ example code.
This in order to have a clear and easy presentation of the various
options available. I'll simplify that code a bit and distribute it to
you and Jukka in another email thread, so that we can have the same
example done with different APIs and presented in the Networking
Forum.
The "big_http_download" example I was talking about is based on
the "http_get" and is a further extension of it. Unlike "http_get",
which makes an HTTP(S) request for a couple KBs of data,
"big_http_download" makes a request for a multi-megabyte file, and
checks the integrity of received data (that it matches a known hash).
That's the difference.


Regards,

Patrik


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: [Zephyr-tsc] Examples for "Zstream" Socket/TLS API

Flykt, Patrik <patrik.flykt@...>
 

Hi,

On Thu, 2018-04-26 at 22:43 +0300, Paul Sokolovsky wrote:
I would like to propose to Patrik, the author of the alternative
proposal, to take the "big_http_download" socket sample as the
baseline for API comparison (followed by the other 4 in-tree samples
if there're enough resources). I also would like to draw attention to
showing portability of a TLS application to other POSIX/BSD Sockets
OSes.
I looked through the socket based samples in the Zephyr source code and
for the sake of presenting the various API options, I think we should
go with something very close to the http_get/ example code. This in
order to have a clear and easy presentation of the various options
available. I'll simplify that code a bit and distribute it to you and
Jukka in another email thread, so that we can have the same example
done with different APIs and presented in the Networking Forum.

Regards,

Patrik


Examples for "Zstream" Socket/TLS API

Paul Sokolovsky
 

Hello,

At yesterday's TSC meeting, it was requested to provide examples of the
usage of 2 contender TLS APIs, to better assess trade-offs they make.
(Please see an earlier email today re: background on TLS API
situation).

Here's an information about usage examples for my Zstream API
(https://github.com/zephyrproject-rtos/zephyr/pull/5985).

Work on examples was the integral part of my PR. Currently, Zephyr has
5 samples for BSD Socket usage in the tree:
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets

While developing my API, I converted each of them in turn from pure BSD
Sockets API to Zstream API. Beyond that, I also added build files
(specifically, Makefiles) which allow to build all these samples on
another POSIX-compatible OS, tested on Linux. In this regard, the
Zstream samples are the same as the original Socket samples they were
derived from - they also have the makefiles and demonstrate portability
to other systems offering BSD Sockets API. Note that requirement of
portability across POSIX OSes was one the basic requirements for the
design of Zstream API.

Beyond converting the existing socket samples, I also converted a WIP
socket-based MQTT client PR, as previously prepared by Gil Pitney:
https://github.com/zephyrproject-rtos/zephyr/pull/5854

With the above work done, for the final version of PR in
https://github.com/zephyrproject-rtos/zephyr/pull/5985 , I decided to
include just one sample, to not overload reviewers, I decided to
include just one example, "the most complex" in a sense,
"big_http_download", which downloads a large file (few MBs) over HTTPS
connection and verifies its hash.

Summing up, the following samples are available for review:

1. https://github.com/zephyrproject-rtos/zephyr/pull/5985 includes a
*standalone* version of "big_http_download" sample, i.e. all related
files are added as new (to keep the socket-based original intact, as of
course Zstream API does not replace BSD Socket API, it's optional layer
on top of it). Direct link:
https://github.com/zephyrproject-rtos/zephyr/pull/5985/files#diff-0bbecb3596925b2de875604e14faa3fd
(may be broken if rebase happens).

2. All the samples mentioned above can be viewed in a diff form in my
branch:
https://github.com/pfalcon/zephyr/tree/net-zstream-api-samples . To
ease the review, I created a pseudo-PR which allows to access the diffs
directly. For example, the diff between the original socket version of
"big_http_download" and its Zstream conversion is here:
https://github.com/pfalcon/zephyr/pull/2/files#diff-63c8f742bbf5c8012d95ebf51d4eeef2


I would like to propose to Patrik, the author of the alternative
proposal, to take the "big_http_download" socket sample as the
baseline for API comparison (followed by the other 4 in-tree samples if
there're enough resources). I also would like to draw attention to
showing portability of a TLS application to other POSIX/BSD Sockets
OSes.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)

Johan Hedberg
 

Hi,

On Thu, Apr 26, 2018, Luiz Augusto von Dentz wrote:
There are a few things that might help:

1. Increate the GATT MTU: We might need to increase the buffer size on
Zephyr and then use Exchange MTU command to enable it. By default, it
is set to 23 bytes only.
2. Enable L2CAP CoC as transport: That might be the fastest way to do
file transfer with BLE but that has to be enabled in mcumgr which I
don't think is the case. I tested the speed of a it some time back and
I got something around 20KBps using BlueZ's l2test.
3. Use the 2Mbps Phy. The code should already be setting a preference to
it automatically, so I *think* it then only depends on whether the
remote side is able to do 2Mbps.

Johan


Re: FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)

Luiz Augusto von Dentz
 

Hi Rodrigo,

There are a few things that might help:

1. Increate the GATT MTU: We might need to increase the buffer size on
Zephyr and then use Exchange MTU command to enable it. By default, it
is set to 23 bytes only.
2. Enable L2CAP CoC as transport: That might be the fastest way to do
file transfer with BLE but that has to be enabled in mcumgr which I
don't think is the case. I tested the speed of a it some time back and
I got something around 20KBps using BlueZ's l2test.

On Thu, Apr 26, 2018 at 6:20 PM, Rodrigo Peixoto <rodrigopex@gmail.com> wrote:
Hello,

I could make the FOTA via Bluetooth work following the documentation
(http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html).
It was not so easy, in fact, some parts of that were tricky to me. Besides
that, I could merge it with the mesh_onoff sample. The FOTA portion of the
code is working properly, but I still need to check if the mesh is running
properly after merging.

The only thing I am concerned about is the upload data rate. It takes too
long when updating an image with 130KB, it takes in average 2 or 3 minutes
(my board: nrf52840 DK). Nowadays, my solution is based on 600 devices, in a
near future, it will be 3000. Make some superficial calculations it will
take at least 6000 minutes which is 100 hours which is 12.5 work days (8
hours per day) running without stop. God, it is a real pain.

Is there anything I can do to speed up that?

Any clue on that? Is there any way to make this in parallel via mesh network
or something like that?

Thank you very much. Best regards, Rodrigo Peixoto Ayna.tech {+55 (82)
98144-8585}

--
Luiz Augusto von Dentz


FOTA takes so long to complete (MCUBoot + mcumgr + Bluetooth)

Rodrigo Peixoto
 

Hello,

I could make the FOTA via Bluetooth work following the documentation (http://docs.zephyrproject.org/samples/subsys/mgmt/mcumgr/smp_svr/README.html). It was not so easy, in fact, some parts of that were tricky to me. Besides that, I could merge it with the mesh_onoff sample. The FOTA portion of the code is working properly, but I still need to check if the mesh is running properly after merging.

The only thing I am concerned about is the upload data rate. It takes too long when updating an image with 130KB, it takes in average 2 or 3 minutes (my board: nrf52840 DK). Nowadays, my solution is based on 600 devices, in a near future, it will be 3000. Make some superficial calculations it will take at least 6000 minutes which is 100 hours which is 12.5 work days (8 hours per day) running without stop. God, it is a real pain.

Is there anything I can do to speed up that?

Any clue on that? Is there any way to make this in parallel via mesh network or something like that?

Thank you very much. Best regards, Rodrigo Peixoto Ayna.tech {+55 (82) 98144-8585}


[RFC] TLS API(s) for Socket-based applications in Zephyr

Paul Sokolovsky
 

Hello,

It occurred to me that the matter of TLS API for BSD Sockets based
application, which was discussed for few months at the online (spoken)
Zephyr Networking Forum meetings and in Github tickets, and recently,
at the TSC meetings, was never RFCed to the development list. As
recently there was request to send additional information to this list,
let me start with some introduction of the matter, so the context was
clear.

Currently, Zephyr supports TLS networking via its "net_app" API, which
is Zephyr-specific and was shown to have some issues with developing
some kinds of applications. There's growing interest in adopting BSD
Sockets API, as also available in Zephyr, as means to address these
issues and increase portability and reusability in general.

At the Networking Forum if December 2017, there was a call to develop
TLS API suitable for use with Sockets. (Just as net_app makes it
possible to use it with net_context native API of Zephyr). I
volunteered to design and implement such an API, and started on it soon
after NY holidays. The initial discussion happened in
https://github.com/zephyrproject-rtos/zephyr/issues/5900 , with
incremental implementation work following in
https://github.com/zephyrproject-rtos/zephyr/pull/5985 (nicknamed
"Zstraam API") . The pull request was targeted for 1.12, as planned LTS
release. It is ready for about a month now - technical issues resolved,
CI passes.

More recently, at the April Networking Forum, there was an alternative
proposal from Patrik Flykt, based around an idea of reusing Sockets API
directly for TLS communication, effectively pushing TLS under the level
of TCP/IP stack. A week-old work-in-progress PR for it is at
https://github.com/zephyrproject-rtos/zephyr/pull/7118 , nicknamed
"setsockopt-based approach" (note that a lot of discussion of it still
happens in #5985).


So, the following summarizes the situation:

1. There's one PR, which has been under detailed development for last 3
months, based on the previous agreement of a way to do it - by now
ready, but not approved (because of thoughts that an alternative may
offer more benefits).

2. There's a new alternative PR, not finished so far, and with some
concerns, both paradigmatic and technical, raised.


There's a concern that this situation deadlocks addition of TLS Sockets
API to 1.12 LTS, that's why this matter was raised for the TSC
consideration, who asked to provide specific additional information to
compare the 2 approaches. It's supposed to be sent in the following
messages.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: fatal error: config-mini-tls1_2.h: No such file or directory

christian tavares
 

Hii 

Indeed, this example is working fine, I tried again and it runs. But, In my application, I don't have an idea why it doesn't work.  

I'm developing an http_client library and I want to add an https support for my lib. I putted my lib in zephyr/subsys. I have a simple application that unique objective to call the http_client library start.
I set my library on Kconfig file NET_APP_TLS, HTTPS, and NET_APP_SERVER, how you can see here https://github.com/OSSystems/zephyr/blob/master/subsys/updatehub/Kconfig . On .config set the CONFIG right:

CONFIG_MBEDTLS=y
CONFIG_MBEDTLS_BUILTIN=y
# CONFIG_MBEDTLS_LIBRARY is not set
CONFIG_MBEDTLS_CFG_FILE="config-mini-tls1_2.h"
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=1500
# CONFIG_MBEDTLS_DEBUG is not set
# CONFIG_MBEDTLS_TEST is not set
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=512
CONFIG_APP_LINK_WITH_MBEDTLS=y

The problem is when I will compile the application happens an error: In file included from zephyr/include/net/http.h:16:0,
from /home/christian/zephyr/subsys/updatehub/updatehub.c:13:
zephyr/include/net/net_app.h:19:33: fatal error: config-mini-tls1_2.h: No such file or directory
#include CONFIG_MBEDTLS_CFG_FILE 


Re: fatal error: config-mini-tls1_2.h: No such file or directory

Jukka Rissanen
 

Hi Christian,

I just tried to compile http-client sample for frdm-k64f with TLS
support and did not see any errors.

cd samples/net/http_client
mkdir build && cd build
cmake .. -DCONF_FILE=prj_tls.conf -DBOARD=frdm_k64f
make


Jukka

On Thu, 2018-04-26 at 06:01 -0700, christian tavares wrote:
I'm developing an http_client library and put it inside of zephyr /
subsys. Out of zephyr I created a simple application that just
performs the call of the start function of my library. However, I'd
like to support https in my library and I've been guided by zephyr /
samples / net / http_client and added the necessary settings.
However, it occurred that the zephyr error could not find the file.
To compile my application I use MakeFile with the following steps:

sample_app: check
(mkdir -p $ (BUILD_DIR_SAMPLE_APP) && \
cd $ (BUILD_DIR_SAMPLE_APP) && \
cmake sample_app \
-G "Unix Makefiles" \
-DBOARD = $ (BOARD)
$ (SOURCE_DIRECTORY) / sample_app && \
make -j $ (nproc))
$ (IMGTOOL) sign \
--key $ (SIGNING_KEY) \
--header-size $ (BOOT_HEADER_LEN) \
--align $ (FLASH_ALIGNMENT) \
--version $ (FIRMWARE_VERSION) \
--included-header \
$ (BUILD_DIR_SAMPLE_APP) /zephyr/zephyr.bin \
signed-sample_app.bin

The board used is frdm_k64f and I use the image signature because I
use mcuboot.

I have already made the changes made in your PR and continue with the
same error in my application and I do not know the real reason.

To make it easier to understand what I'm talking about, I'm sending
the link from my fork to my application. https://github.com/OSSystems
/zephyr/tree/master/subsys/updatehub


Re: fatal error: config-mini-tls1_2.h: No such file or directory

christian tavares
 

I'm developing an http_client library and put it inside of zephyr / subsys. Out of zephyr I created a simple application that just performs the call of the start function of my library. However, I'd like to support https in my library and I've been guided by zephyr / samples / net / http_client and added the necessary settings. However, it occurred that the zephyr error could not find the file. To compile my application I use MakeFile with the following steps:
 
sample_app: check
(mkdir -p $ (BUILD_DIR_SAMPLE_APP) && \
cd $ (BUILD_DIR_SAMPLE_APP) && \
cmake sample_app \
-G "Unix Makefiles" \
-DBOARD = $ (BOARD)
$ (SOURCE_DIRECTORY) / sample_app && \
make -j $ (nproc))
$ (IMGTOOL) sign \
--key $ (SIGNING_KEY) \
--header-size $ (BOOT_HEADER_LEN) \
--align $ (FLASH_ALIGNMENT) \
--version $ (FIRMWARE_VERSION) \
--included-header \
$ (BUILD_DIR_SAMPLE_APP) /zephyr/zephyr.bin \
signed-sample_app.bin
 
The board used is frdm_k64f and I use the image signature because I use mcuboot.
 
I have already made the changes made in your PR and continue with the same error in my application and I do not know the real reason.
 
To make it easier to understand what I'm talking about, I'm sending the link from my fork to my application. https://github.com/OSSystems/zephyr/tree/master/subsys/updatehub


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Johan Hedberg
 

Hi,

This was already identified as a bug in meshctl by Steve, a week ago or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

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 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
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 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@gmail.com>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@bluetooth.com>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, "users@lists.zephyrproject.org" <users@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@gmail.com<mailto:vikrant8051@gmail.com>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr.

Kai


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Kai Ren
 

Hi Vikrant,

I just did two tests today, the detail is:

 

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

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 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56 

GATT-TX:     93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be 

GATT-TX:     75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c 

GATT-TX:     3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9 

GATT-TX:     e9 60 

GATT-RX:     03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 

GATT-RX:     68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 

GATT-RX:     01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 

GATT-RX:     49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 

GATT-RX:     4c bf 

Got provisioning data (65 bytes)

       03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68 

       cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01 

       32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49 

       a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c 

       bf 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX:     03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3 

GATT-TX:     83 c4 

GATT-RX:     03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 

GATT-RX:     90 76 

Got provisioning data (17 bytes)

       05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90 

       76 

GATT-TX:     03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18 

GATT-TX:     d8 91 

GATT-RX:     03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 

GATT-RX:     b1 ea 

Got provisioning data (17 bytes)

       06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1 

       ea 

Confirmation Validated

S-Key  37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14 

S-Nonce       d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb 

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 13 

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00 

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca 

DataEncrypted + mic 5b 

GATT-TX:     03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 

GATT-TX:     6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 

GATT-TX:     0f ca 5b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]# 

 

 

2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x1915e08

Open-Prov: 0x19149d0

Open-Prov: proxy 0x19124d8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

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 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4 

GATT-TX:     51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4 

GATT-TX:     0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7 

GATT-TX:     fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f 

GATT-TX:     e1 0f 

GATT-RX:     03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 

GATT-RX:     4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 

GATT-RX:     1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 

GATT-RX:     e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 

GATT-RX:     7c 49 

Got provisioning data (65 bytes)

       03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e 

       1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c 

       5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3 

       32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c 

       49 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): RZTCNG

GATT-TX:     03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd 

GATT-TX:     fa f7 

GATT-RX:     03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 

GATT-RX:     3c a3 

Got provisioning data (17 bytes)

       05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c 

       a3 

GATT-TX:     03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27 

GATT-TX:     dd dc 

GATT-RX:     03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 

GATT-RX:     b7 9f 

Got provisioning data (17 bytes)

       06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7 

       9f 

Confirmation Validated

S-Key  2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec 

S-Nonce       69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03 

DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 1b 

DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d 

DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71 

DataEncrypted + mic 2b 

GATT-TX:     03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 

GATT-TX:     3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 

GATT-TX:     3c 71 2b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 011b

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

 

              Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)

              Identity for node 011b

Trying to connect to mesh

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Proxy Out Data started

Trying to open mesh session

GATT-RX:     01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4 

GATT-RX:     0a 41 fa b0 af 32 0b 

iv_upd_state = IV_UPD_NORMAL

Mesh session is open

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02 

GATT-TX:     a7 77 d9 51 

GATT-TX:     00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07 

GATT-TX:     57 67 06 0c 51 02 

GATT-RX:     02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0 

GATT-RX:     78 86 79 a1 ea fd 

Proxy Whitelist filter length: 0

GATT-RX:     00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e 

GATT-RX:     4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d 

GATT-RX:     00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb 

GATT-RX:     2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9 

GATT-RX:     00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39 

GATT-RX:     97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71 

GATT-RX:     00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc 

GATT-RX:     7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30 

GATT-RX:     00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92 

GATT-RX:     ea eb dc 22 e8 61 3e d5 02 5b 3c 12 

       Composition data for node 011b {

  "cid":"05f1",

  "pid":"0000",

  "vid":"0000",

  "crpl":"000a",

  "features":{

    "relay":true,

    "proxy":true,

    "friend":false,

    "lpn":false

  },

  "elements":[

    {

      "elementIndex":0,

      "location":"0000",

      "models":[

        "0000",

        "0001",

        "0002",

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":1,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":2,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":3,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    }

  ]

}

GATT-TX:     00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65 

GATT-TX:     0b f9 13 7b fb 95 19 e4 a5 

[Zephyr-Node-011b]

 

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

 

Regards,

Kai

 

 

 

From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

 

HI Kai,

Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

 

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX:     03 00 10
GATT-RX:     03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
     01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX:     03 02 00 00 00 00 00
GATT-TX:     03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX:     2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX:     4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX:     31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX:     52 ea
GATT-RX:     43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX:     10 28 b4 89
GATT-RX:     83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX:     87 b9 2b a3
GATT-RX:     83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX:     b7 1a f5 1d
GATT-RX:     c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
     03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
     28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
     14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
     5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
     27
GATT-TX:     03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX:     82 90
GATT-RX:     03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX:     59 d0
Got provisioning data (17 bytes)
     05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
     d0
GATT-TX:     03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX:     a2 b6
GATT-RX:     03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX:     f1 88
Got provisioning data (17 bytes)
     06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
     88
Confirmation Validated
S-Key     bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce     1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey     24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data     18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data     00 00 00 00 00 00 05 01 00
DataEncrypted + mic     6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic     44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic     67
GATT-TX:     03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX:     37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX:     50 01 67
GATT-RX:     03 08
Got provisioning data (1 bytes)
     08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

 

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...> wrote:

Hi Kai, 

 

Yes, you are right. Thanks for sharing it. 

 

Regards,

vikrant

 

 

On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...> wrote:

Hi Vikrant8051, 

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr. 

Kai  

 


Re: fatal error: config-mini-tls1_2.h: No such file or directory

Jukka Rissanen
 

Hi,

On Wed, 2018-04-25 at 19:35 -0700, Graham Stott wrote:
Is the following line missing the quotes (“) before the file name?

#include CONFIG_MBEDTLS_CFG_FILE"

Should be

#include “CONFIG_MBEDTLS_CFG_FILE"

Quotes should not placed here, now you are trying to include a file
that is called CONFIG_MBEDTLS_CFG_FILE which will not work.




From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject
.org] On Behalf Of Marti Bolivar
Sent: Wednesday, April 25, 2018 1:25 PM
To: christian tavares <christiantavarest@hotmail.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] fatal error: config-mini-tls1_2.h: No
such file or directory

Hi Christian,

Can you please paste the complete and exact steps of what you tried,
and not just the error? It will be difficult for people to help you
without knowing exactly what you did.

Please include:
- The exact cmake command line you typed, and its output
- The exact compilation command line you typed, and its output

Thanks,
Marti

On Wed, Apr 25, 2018 at 2:14 PM, christian tavares <christiantavarest
@hotmail.com> wrote:
Hello!!

I'm developing a http_client application and I want to include
https support. But, happends

"[ 95%] Built target ext__lib__crypto__mbedtls
In file included from
/home/christian/zephyr/include/net/http.h:16:0,
from
/home/christian/zephyr/subsys/my_application/aplication.c:13:
/home/christian/zephyr/include/net/net_app.h:19:33: fatal error:
config-mini-tls1_2.h: No such file or directory
#include CONFIG_MBEDTLS_CFG_FILE"

I try to build the http_client sample and happend the same error,
I'm using the master branch.
I don't know how I can solve this problem!
Could you check that you have similar configuration as the
samples/net/http_client/prj_tls.conf is having? I just tried that app
and it could find the cfg file just fine.

While doing some testing I noticed a compilation issue in http-client
sample that is fixed by PR#7204
https://github.com/zephyrproject-rtos/zephyr/pull/7204


Cheers,
Jukka


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

vikrant8051 <vikrant8051@...>
 

HI Kai,

Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX:     03 00 10
GATT-RX:     03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
     01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX:     03 02 00 00 00 00 00
GATT-TX:     03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX:     2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX:     4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX:     31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX:     52 ea
GATT-RX:     43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX:     10 28 b4 89
GATT-RX:     83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX:     87 b9 2b a3
GATT-RX:     83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX:     b7 1a f5 1d
GATT-RX:     c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
     03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
     28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
     14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
     5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
     27
GATT-TX:     03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX:     82 90
GATT-RX:     03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX:     59 d0
Got provisioning data (17 bytes)
     05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
     d0
GATT-TX:     03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX:     a2 b6
GATT-RX:     03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX:     f1 88
Got provisioning data (17 bytes)
     06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
     88
Confirmation Validated
S-Key     bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce     1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey     24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data     18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data     00 00 00 00 00 00 05 01 00
DataEncrypted + mic     6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic     44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic     67
GATT-TX:     03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX:     37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX:     50 01 67
GATT-RX:     03 08
Got provisioning data (1 bytes)
     08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...> wrote:
Hi Kai, 

Yes, you are right. Thanks for sharing it. 

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...> wrote:

Hi Vikrant8051, 

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr. 

Kai  


3561 - 3580 of 8033