Date   

Re: Adding own Library to project

Patrick Boettcher <patrick.boettcher@...>
 

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

Hi Patrick,

If you still want to keep your library (module), another way you can
do is to add your library as the link dependency for the application
library (app) by the following:

target_link_libraries(app your_lib_name)
Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Re: Adding own Library to project

Li, Jun R
 

Hi Patrick,

If you still want to keep your library (module), another way you can do is to add your library as the link dependency for the application library (app) by the following:

target_link_libraries(app your_lib_name)

Regards,
Jun


On 6/13/18, 06:37, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

Hi Patrick,

On Wed, 13 Jun 2018 10:54:57 +0200
König Patrick <Patrick.Koenig@...> wrote:

> Hello,
>
> My name is Patrick König. I am new to zephyr. I just wrote a couple
> of functions as additions to the zephyr/samples/subsys/usb/cdc_acm
> Sample Project for the Nordic nRf52840. These are working fine and
> have been tested.
>
> Now I moved these functions from the main.c file to a custom module
> (.c and .h) within the src folder of my project. While doing so I
> managed to build the object file by keeping the sources in the source
> folder as described in the documentation. Unfortunately I get errors
> from the linker telling me that I have undefined references to my
> functions.

The most convenient way of adding additional sources to your
application outside zephyr is using

target_sources(app PRIVATE src1.c src2.c)

in the CMakeLists.txt of your application (there where you are
including Zephyr's boilerplate.cmake).

I'm not sure whether that answers your question. Feel free to give some
more details and code-example if appropriate.

best regards,
--
Patrick.


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

I understood what you meant. And those are the steps I followed. I used
Nordic's new iOS mesh app and used its "node reset" feature. Then I
reprovisioned and after that did a power-cycle. After that the node came
back up as provisioned.

Johan

On Wed, Jun 13, 2018, vikrant8051 wrote:
Hi Johan,

I've completely removed NVS from my local project.
Even after that facing same issue.

If you provision & configure -> reset the board -> then it work as
expected.

But I'm not talking about power reset...I'm talking about Provisioner
node-reset command.

For e.g.

provision & configured DEVICE using #meshctl --> send node-reset command
via #meshctl --> unprovision state --> provision & configure it again -->
now do power reset/ hardware reset -> Here device should be
in provisioned state but I always found it in Unprovisioned state.


Thank You !!

On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@...>
wrote:

Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
wrote:

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it
worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
wrote:

Hi,

If after complete or partial provisioning, execute *node-reset*
command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!




Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 


Hi Johan,

I've completely removed NVS from my local project.
Even after that facing same issue.

If you provision & configure -> reset the board -> then it work as expected.

But I'm not talking about power reset...I'm talking about Provisioner node-reset command.

For e.g.

provision & configured DEVICE using #meshctl  --> send node-reset command via #meshctl  --> unprovision state  --> provision & configure it again --> now do power reset/ hardware reset -> Here device should be
in provisioned state but I always found it in Unprovisioned state.


Thank You !!

On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
> Hi Johan,
>
> It is with default #FCB.
>
> On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
> wrote:
>
> > Hi Vikrant,
> >
> > Is this with NFFS or FCB? I remember testing this with FCB and it worked
> > correctly.
> >
> > Johan
> >
> > On Wed, Jun 13, 2018, Vikrant More wrote:
> > > Hi,
> > >
> > > Yes, I confirmed my observation. And happening this every time.
> > >
> > > I also tried it with #nRFMesh app. In that case too, if I do
> > > (provision + configuration) -> ( node-reset ) -> (provision +
> > > configuration) --> Reset/ Power down the board-> Device found in
> > > unprovisioned state.
> > >
> > > Thank You !!
> > >
> > > On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > If after complete or partial provisioning, execute *node-reset* command
> > > > then in that case I have observe following things :
> > > >
> > > > 1) Node get reprovision
> > > > 2) but after reboot, it boot as unprovisioned device.
> > > >
> > > > Has anybody observe this ?
> > > >
> > > > Thank You !! > > > >
> > > >
> >


Re: bt settings - how is it done ?

Johan Hedberg
 

Hi Jehudi,

On Wed, Jun 13, 2018, laczenJMS wrote:
In the settings part of bt there seems to be a cool way to generate a
list of settings with their set, commit and export handlers. Items are
added to this list by a macro BT_SETTINGS_DEFINE() and all items seem
to be processed based upon linker defined _bt_stettings_start[] and
_bt_settings_end[].

This is a very nice expandable way to generate bt_settings. I am
however not sure if I completely understand how it works, is there a
place where I can get some more info on how this works ?
The linker section is defined in include/linker/common-rom.ld, and
variables are placed there using the __in_section() specifier (see
subsys/bluetooth/host/settings.h).

I am puzzled by the fact that mesh items are stored under
"/bt/mesh/...", this seems to mean that BT_SETTINGS_DEFINE() inserts
the handlers "under" "/bt".
subsys/bluetooth/host/settings.c registers a settings_handler with the
name "bt", and that's used as the central point to process all
bt_settings handlers, so yes everything is under the "bt/..." path. The
name that's given to BT_SETTINGS_DEFINE() is the first path component
that follows "bt/".

Johan


bt settings - how is it done ?

laczenJMS
 

Hi,

In the settings part of bt there seems to be a cool way to generate a
list of settings with their set, commit and export handlers. Items are
added to this list by a macro BT_SETTINGS_DEFINE() and all items seem
to be processed based upon linker defined _bt_stettings_start[] and
_bt_settings_end[].

This is a very nice expandable way to generate bt_settings. I am
however not sure if I completely understand how it works, is there a
place where I can get some more info on how this works ?

I am puzzled by the fact that mesh items are stored under
"/bt/mesh/...", this seems to mean that BT_SETTINGS_DEFINE() inserts
the handlers "under" "/bt".

Thanks,

Jehudi


Re: Adding own Library to project

Patrick Boettcher <patrick.boettcher@...>
 

Hi Patrick,

On Wed, 13 Jun 2018 10:54:57 +0200
König Patrick <Patrick.Koenig@...> wrote:

Hello,

My name is Patrick König. I am new to zephyr. I just wrote a couple
of functions as additions to the zephyr/samples/subsys/usb/cdc_acm
Sample Project for the Nordic nRf52840. These are working fine and
have been tested.

Now I moved these functions from the main.c file to a custom module
(.c and .h) within the src folder of my project. While doing so I
managed to build the object file by keeping the sources in the source
folder as described in the documentation. Unfortunately I get errors
from the linker telling me that I have undefined references to my
functions.
The most convenient way of adding additional sources to your
application outside zephyr is using

target_sources(app PRIVATE src1.c src2.c)

in the CMakeLists.txt of your application (there where you are
including Zephyr's boilerplate.cmake).

I'm not sure whether that answers your question. Feel free to give some
more details and code-example if appropriate.

best regards,
--
Patrick.


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
wrote:

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
wrote:

Hi,

If after complete or partial provisioning, execute *node-reset* command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



Adding own Library to project

König Patrick <Patrick.Koenig@...>
 

Hello,

 

My name is Patrick König. I am new to zephyr. I just wrote a couple of functions as additions to the zephyr/samples/subsys/usb/cdc_acm Sample Project for the Nordic nRf52840. These are working fine and have been tested.

 

Now I moved these functions from the main.c file to a custom module (.c and .h) within the src folder of my project. While doing so I managed to build the object file by keeping the sources in the source folder as described in the documentation.
Unfortunately I get errors from the linker telling me that I have undefined references to my functions.

 

So my question is: Is there a specific include process for adding custom modules to a project while using zephyr? Or did I miss a step in my process?

 

I have searched github for a similar issue, but I had no luck so far finding a solution, that’s why I hope to get an answer this way.

 

Thanks a lot

 

Patrick König

 

NewTec GmbH

 

System-Entwicklung und Beratung

 

Heinrich-von-Stephan-Str. 8

 

79100 Freiburg

 

 

 

Telefon: +49 76121117-42

 

Telefax: +49 76121117-99

 

email:   Patrick.Koenig@...

 

web:     www.newtec.de

 

 

 

------------------------------------------------------------------------------------------------------

 

Geschäftsführer: Johannes Werbach, Harald Molle, Ulrich Schwer, Michael Tröscher Registergericht Memmingen - HRB 7236  USt.-IdNr. DE130850199

 

------------------------------------------------------------------------------------------------------

 

 

 

 

 

 

 

 

 


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
> Hi,
>
> Yes, I confirmed my observation. And happening this every time.
>
> I also tried it with #nRFMesh app. In that case too, if I do
> (provision + configuration) -> ( node-reset ) -> (provision +
> configuration) --> Reset/ Power down the board-> Device found in
> unprovisioned state.
>
> Thank You !!
>
> On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...> wrote:
>
> > Hi,
> >
> > If after complete or partial provisioning, execute *node-reset* command
> > then in that case I have observe following things :
> >
> > 1) Node get reprovision
> > 2) but after reboot, it boot as unprovisioned device.
> >
> > Has anybody observe this ?
> >
> > Thank You !! > >
> >


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...> wrote:

Hi,

If after complete or partial provisioning, execute *node-reset* command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision + configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...> wrote:
Hi,

If after complete or partial provisioning, execute node-reset command then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



#BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi,

If after complete or partial provisioning, execute node-reset command then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!


Re: Building app with ext libraries (mcumgr for example)

Patrick Boettcher <patrick.boettcher@...>
 

Hi

On Wed, 6 Jun 2018 15:47:02 +0200
"Patrick Boettcher" <patrick.boettcher@...> wrote:

Hi,

On Wed, 6 Jun 2018 13:38:50 +0000
"Bøe, Sebastian" <Sebastian.Boe@...> wrote:

Hi,

I was able to reproduce the issue with 1.11.
Interestingly, the problem does not occur on the latest master.

This patch
https://github.com/SebastianBoe/zephyr/commit/f7c609f994a9433aa3d1e0da06f14a47c9c5174d
resolves the issue on 1.11. and seems reasonably clean to me.
But I need to reproduce the issue on master before I can apply
it ...

What is going on here is that mcumgr is a zephyr cmake library that
uses another zephyr cmake library. When one library uses another it
should link with it to ensure that any build-requirements, like
include paths, are inherited.
Great, thanks for your help.

If this is a target_link_libraries()-issue I still wonder why it
worked when activated things "manually" via menuconfig.
A colleague (thanks Ismael) has bisected zephyr between 1.11 and 1.12
to find that dd5449a77b5c914 is the first commit without the link-error
and thus explains why it is working on master but not on 1.11 .

regards,
--
Patrick.


Re: Using a predefined passkey on a BLE peripheral device with no input/output

Li, Jun R
 

An GitHub issue was opened to address this requirement: https://github.com/zephyrproject-rtos/zephyr/issues/8350

 

Thank you!

Jun

 

 

From: <devel@...> on behalf of vikrant8051 <vikrant8051@...>
Date: Tuesday, June 12, 2018 at 14:02
To: "Hedberg, Johan" <johan.hedberg@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Using a predefined passkey on a BLE peripheral device with no input/output

 

Hi Johan,

 

This is not new requirement. I had asked similar question on Jan 25, 2018

 

This is for your reference,

 

 

Need was static passkey for pairing. But no one entertained that question at that time. 😊

 

Thanks !!

 

On Wed, Jun 13, 2018, 2:13 AM Johan Hedberg <johan.hedberg@...> wrote:

Hi Jun,

We don't have such a feature currently (no one has asked for it until
now). Do I understand right that you want to have a per-device static
random passkey that's e.g. on a sticker on the device, in the packaging
or the manual, and the user then needs to read that and enter it into
the other device that's initiating the pairing?

I would do this as a runtime API instead of Kconfig since some devices
may need to dig out the value from a special flash location or factory
register.

By calling the new (yet to be defined) API it would essentially force
our IO Capability to DisplayOnly, however instead of using the
passkey_display callback from struct bt_conn_auth_cb we would use the
value given by the app using the new API? I suppose we should also
reject pairings from any remote device which doesn't have sufficient IO
capabilities to perform passkey entry (say, they have DisplayOnly or
NoInputNoOutput), right? Are there any special considerations with
legacy pairing vs secure connections that should be taken into account?

Could you open a github issue for this, so we can document the exact
requirement, and get it implemented in time for Zephyr 1.13?

Johan

On Tue, Jun 12, 2018, Li, Jun R wrote:
> Hi Johan,
> Is that a way to pre-set the static passkey by like a Kconfig item? Six zeros are not good as a passkey.
>
> Regards,
> Jun
>
>
> On 6/12/18, 01:21, "Johan Hedberg" <johan.hedberg@...> wrote:
>
>     Hi Jun,
>     
>     On Mon, Jun 11, 2018, Li, Jun R wrote:
>     > I have a NRF51 BLE device which doesn’t have either a display or a
>     > keyboard, and would like to use a static passkey to secure the
>     > connection establishment. Is it possible to use a static pre-defined
>     > passkey in Zephyr’s BLE  stack and how is the static passkey defined?
>     
>     The normal way to configure pairing on a device which lacks both output
>     and input capabilities is to set NoInputNoOutput as the IO capability in
>     the Security Manager Protocol. This will then cause an all-zeroes
>     "pre-defined" passkey to be used for pairing. The simplest way to do
>     this is by not registering a "struct bt_conn_auth_cb" using the
>     bt_conn_auth_cb_register() API, i.e. remove that call from your app if
>     you have it there.
>     
>     Johan
>     
>





Re: Using a predefined passkey on a BLE peripheral device with no input/output

vikrant8051 <vikrant8051@...>
 

Hi Johan,

This is not new requirement. I had asked similar question on Jan 25, 2018

This is for your reference,


Need was static passkey for pairing. But no one entertained that question at that time. 😊

Thanks !!

On Wed, Jun 13, 2018, 2:13 AM Johan Hedberg <johan.hedberg@...> wrote:
Hi Jun,

We don't have such a feature currently (no one has asked for it until
now). Do I understand right that you want to have a per-device static
random passkey that's e.g. on a sticker on the device, in the packaging
or the manual, and the user then needs to read that and enter it into
the other device that's initiating the pairing?

I would do this as a runtime API instead of Kconfig since some devices
may need to dig out the value from a special flash location or factory
register.

By calling the new (yet to be defined) API it would essentially force
our IO Capability to DisplayOnly, however instead of using the
passkey_display callback from struct bt_conn_auth_cb we would use the
value given by the app using the new API? I suppose we should also
reject pairings from any remote device which doesn't have sufficient IO
capabilities to perform passkey entry (say, they have DisplayOnly or
NoInputNoOutput), right? Are there any special considerations with
legacy pairing vs secure connections that should be taken into account?

Could you open a github issue for this, so we can document the exact
requirement, and get it implemented in time for Zephyr 1.13?

Johan

On Tue, Jun 12, 2018, Li, Jun R wrote:
> Hi Johan,
> Is that a way to pre-set the static passkey by like a Kconfig item? Six zeros are not good as a passkey.
>
> Regards,
> Jun
>
>
> On 6/12/18, 01:21, "Johan Hedberg" <johan.hedberg@...> wrote:
>
>     Hi Jun,
>     
>     On Mon, Jun 11, 2018, Li, Jun R wrote:
>     > I have a NRF51 BLE device which doesn’t have either a display or a
>     > keyboard, and would like to use a static passkey to secure the
>     > connection establishment. Is it possible to use a static pre-defined
>     > passkey in Zephyr’s BLE  stack and how is the static passkey defined?
>     
>     The normal way to configure pairing on a device which lacks both output
>     and input capabilities is to set NoInputNoOutput as the IO capability in
>     the Security Manager Protocol. This will then cause an all-zeroes
>     "pre-defined" passkey to be used for pairing. The simplest way to do
>     this is by not registering a "struct bt_conn_auth_cb" using the
>     bt_conn_auth_cb_register() API, i.e. remove that call from your app if
>     you have it there.
>     
>     Johan
>     
>






Re: Using a predefined passkey on a BLE peripheral device with no input/output

Li, Jun R
 

Hi Johan,

My requirement is exactly like what you said: every device has a unique passkey stored and labeled on this case. The user needs to check the case to get the right passkey and enter it when paring the device.

Sure, I'll create a GitHub issue to request this feature. Thanks very much for your support!

Regards,
Jun


On 6/12/18, 13:43, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

We don't have such a feature currently (no one has asked for it until
now). Do I understand right that you want to have a per-device static
random passkey that's e.g. on a sticker on the device, in the packaging
or the manual, and the user then needs to read that and enter it into
the other device that's initiating the pairing?

I would do this as a runtime API instead of Kconfig since some devices
may need to dig out the value from a special flash location or factory
register.

By calling the new (yet to be defined) API it would essentially force
our IO Capability to DisplayOnly, however instead of using the
passkey_display callback from struct bt_conn_auth_cb we would use the
value given by the app using the new API? I suppose we should also
reject pairings from any remote device which doesn't have sufficient IO
capabilities to perform passkey entry (say, they have DisplayOnly or
NoInputNoOutput), right? Are there any special considerations with
legacy pairing vs secure connections that should be taken into account?

Could you open a github issue for this, so we can document the exact
requirement, and get it implemented in time for Zephyr 1.13?

Johan

On Tue, Jun 12, 2018, Li, Jun R wrote:
> Hi Johan,
> Is that a way to pre-set the static passkey by like a Kconfig item? Six zeros are not good as a passkey.
>
> Regards,
> Jun
>
>
> On 6/12/18, 01:21, "Johan Hedberg" <johan.hedberg@...> wrote:
>
> Hi Jun,
>
> On Mon, Jun 11, 2018, Li, Jun R wrote:
> > I have a NRF51 BLE device which doesn’t have either a display or a
> > keyboard, and would like to use a static passkey to secure the
> > connection establishment. Is it possible to use a static pre-defined
> > passkey in Zephyr’s BLE stack and how is the static passkey defined?
>
> The normal way to configure pairing on a device which lacks both output
> and input capabilities is to set NoInputNoOutput as the IO capability in
> the Security Manager Protocol. This will then cause an all-zeroes
> "pre-defined" passkey to be used for pairing. The simplest way to do
> this is by not registering a "struct bt_conn_auth_cb" using the
> bt_conn_auth_cb_register() API, i.e. remove that call from your app if
> you have it there.
>
> Johan
>
>


Re: Using a predefined passkey on a BLE peripheral device with no input/output

Johan Hedberg
 

Hi Jun,

We don't have such a feature currently (no one has asked for it until
now). Do I understand right that you want to have a per-device static
random passkey that's e.g. on a sticker on the device, in the packaging
or the manual, and the user then needs to read that and enter it into
the other device that's initiating the pairing?

I would do this as a runtime API instead of Kconfig since some devices
may need to dig out the value from a special flash location or factory
register.

By calling the new (yet to be defined) API it would essentially force
our IO Capability to DisplayOnly, however instead of using the
passkey_display callback from struct bt_conn_auth_cb we would use the
value given by the app using the new API? I suppose we should also
reject pairings from any remote device which doesn't have sufficient IO
capabilities to perform passkey entry (say, they have DisplayOnly or
NoInputNoOutput), right? Are there any special considerations with
legacy pairing vs secure connections that should be taken into account?

Could you open a github issue for this, so we can document the exact
requirement, and get it implemented in time for Zephyr 1.13?

Johan

On Tue, Jun 12, 2018, Li, Jun R wrote:
Hi Johan,
Is that a way to pre-set the static passkey by like a Kconfig item? Six zeros are not good as a passkey.

Regards,
Jun


On 6/12/18, 01:21, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

On Mon, Jun 11, 2018, Li, Jun R wrote:
> I have a NRF51 BLE device which doesn’t have either a display or a
> keyboard, and would like to use a static passkey to secure the
> connection establishment. Is it possible to use a static pre-defined
> passkey in Zephyr’s BLE stack and how is the static passkey defined?

The normal way to configure pairing on a device which lacks both output
and input capabilities is to set NoInputNoOutput as the IO capability in
the Security Manager Protocol. This will then cause an all-zeroes
"pre-defined" passkey to be used for pairing. The simplest way to do
this is by not registering a "struct bt_conn_auth_cb" using the
bt_conn_auth_cb_register() API, i.e. remove that call from your app if
you have it there.

Johan


Re: Using a predefined passkey on a BLE peripheral device with no input/output

Li, Jun R
 

Hi Johan,
Is that a way to pre-set the static passkey by like a Kconfig item? Six zeros are not good as a passkey.

Regards,
Jun


On 6/12/18, 01:21, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

On Mon, Jun 11, 2018, Li, Jun R wrote:
> I have a NRF51 BLE device which doesn’t have either a display or a
> keyboard, and would like to use a static passkey to secure the
> connection establishment. Is it possible to use a static pre-defined
> passkey in Zephyr’s BLE stack and how is the static passkey defined?

The normal way to configure pairing on a device which lacks both output
and input capabilities is to set NoInputNoOutput as the IO capability in
the Security Manager Protocol. This will then cause an all-zeroes
"pre-defined" passkey to be used for pairing. The simplest way to do
this is by not registering a "struct bt_conn_auth_cb" using the
bt_conn_auth_cb_register() API, i.e. remove that call from your app if
you have it there.

Johan


Re: What information shall be persistent to restore BLE bond after power cycling?

Li, Jun R
 

Hi Johan and Vikrant,
Thanks for the detailed guidelines! Actually, my device works with all these settings added, which I didn't realized because the whole flash memory of the device was erased by the "make flash" command. Without reflashing the device, I can see it works perfectly.

Thanks again!

Jun

On 6/12/18, 00:59, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

All keys that were distributed or generated during pairing should get
stored. The most important one is the Long Term Key (LTK). The only
situation when it would not get stored is if one of the sides did not
set the bonding flag (i.e. wanted to do pairing just for that one
connection but not persistently). You'd be able to see if the flag was
set either by enabling debug logs for the Security Manager protocol
(CONFIG_BT_DEBUG_SMP=y) or by getting HCI traces, using e.g.
CONFIG_BT_DEBUG_MONITOR and btmon on a Linux host.

I would also still double-check that you have CONFIG_BT_SETTINGS=y in
your <build dir>/zephyr/.config file.

Johan

On Tue, Jun 12, 2018, Li, Jun R wrote:
> Hi Vikrant,
> Thanks for help! Yes, I did the same thing in my project, but still was not lucky to get it connected to my iPhone after its power cycling, unless I get iPhone to forget my device firstly.
>
> What exact information will be stored for restoring the secured bonding to a phone?
>
> Regards,
> Jun
>
>
> From: Vikrant More <vikrant8051@...>
> Date: Monday, June 11, 2018 at 23:30
> To: Jun Li <jun.r.li@...>
> Cc: "devel@..." <devel@...>
> Subject: Re: [Zephyr-devel] What information shall be persistent to restore BLE bond after power cycling?
>
> Hi Jun Li,
>
> You have to enable persistent storage in your application.
>
> For that,
>
> 1) add #include <settings/settings.h> in main.c
>
> 2) add
>
> if (IS_ENABLED(CONFIG_SETTINGS)) {
> settings_load();
> }
>
> in bt_ready() function
>
> 3) add
>
> CONFIG_BT_SETTINGS=y
> CONFIG_FLASH=y
> CONFIG_FLASH_PAGE_LAYOUT=y
> CONFIG_FLASH_MAP=y
> CONFIG_FCB=y
> CONFIG_SETTINGS=y
> CONFIG_SETTINGS_FCB=y
>
>
> in prj.conf
>
>
> For details refer -> zephyr/samples/bluetooth/peripheral example.
>
> regards,
> vikrant
>
>
> On Tue, Jun 12, 2018 at 4:17 AM, Li, Jun R <jun.r.li@...<mailto:jun.r.li@...>> wrote:
> Hi,
>
> I’m building a BLE application based on a NRF51 board with pass key support. The device can be connected and bonded with a mobile phone after the pass key was correctly entered, and can be reconnected after disconnection. However, the connection can’t be established any more after the device rebooted unless I click “Forget the device” in my phone’s Bluetooth settings. I guess that some parameters related to bonding shall be stored into “settings”, but wasn’t able to figure out what kind of parameters shall be saved and restored. Can anyone give any clue to this? Thank you!
>
> Also, I’ve called “settings_load()” in the function “bt_ready()” but it seems not helpful.
>
> Regards,
> Jun Li
>
>
>
>
>
>

4021 - 4040 of 8778