Date   

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
>
>
>
>
>
>


Re: Bluetooth Multiple Central Connections

Daniel Widmann
 

Hi Johan,

I already tried to increase CONFIG_BT_HCI_CMD_COUNT, but I ended up with a MPU fault. Increasing the TX stack size didn't help with the MPU fault either.
I can call scan_start from the main thread, so its not a pressing issue for me right now. 

I think the main issue is not the context of the callback, but the synchronous invocation of the callback while processing a HCI command. Anyways, invoking the callback from another thread would also fix that issue.

***** MPU FAULT *****
  Executing thread ID (thread): 0x20000724
  Faulting instruction address:  0x15294
  Data Access Violation
  Address: 0x707
Fatal fault in thread 0x20000724! Aborting.


Thanks,
Daniel

On Tue, Jun 12, 2018 at 12:51 AM Johan Hedberg <johan.hedberg@...> wrote:
Hi Daniel,

On Mon, Jun 11, 2018, Daniel Widmann wrote:
> Zephyr will lock up if I try to enable scanning in the '*Failed to connect*'
> callback.
> In the *failed to connect* case, the callback is called from the hci tx
> thread while a command is processed (I assume
> BT_HCI_OP_LE_CREATE_CONN_CANCEL). This behavior was recently introduced here
> <https://github.com/zephyrproject-rtos/zephyr/commit/a59f544fb417bd9469a9c378dc23bb54ff1e395d>.
> In  *bt_le_scan_start, *Zephyr will wait forever when it tries to allocate
> a new buffer from *hci_cmd_pool*.
>
> Should it be possible to enable scanning '*Failed to connect*'
> callback? Currently
> the Bluetooth central sample will simply stop if it failed to connect.

I think this should be possible. We can discuss whether the TX thread is
the right context for the controller to do the bt_recv() call from, but
meanwhile a simple solution should be to just increase the number of HCI
command buffers, i.e. set CONFIG_BT_HCI_CMD_COUNT to some higher value.

Johan


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

Johan Hedberg
 

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?

vikrant8051 <vikrant8051@...>
 

Hi Johan,

Could you please elaborate when to use what out of following things ?

BT_GATT_CHRC_AUTH,

BT_GATT_PERM_READ_AUTHEN
BT_GATT_PERM_WRITE_AUTHEN

BT_GATT_PERM_READ_ENCRYPT
BT_GATT_PERM_WRITE_ENCRYPT

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

int bt_conn_security(struct bt_conn *conn, bt_security_t sec)

How we could use it & where we should put it in any BLE app ?

Thanks !!




On Tue, Jun 12, 2018 at 1:29 PM, 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
>
>
>
>
>
>


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

Johan Hedberg
 

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






Re: Bluetooth Multiple Central Connections

Johan Hedberg
 

Hi Daniel,

On Mon, Jun 11, 2018, Daniel Widmann wrote:
Zephyr will lock up if I try to enable scanning in the '*Failed to connect*'
callback.
In the *failed to connect* case, the callback is called from the hci tx
thread while a command is processed (I assume
BT_HCI_OP_LE_CREATE_CONN_CANCEL). This behavior was recently introduced here
<https://github.com/zephyrproject-rtos/zephyr/commit/a59f544fb417bd9469a9c378dc23bb54ff1e395d>.
In *bt_le_scan_start, *Zephyr will wait forever when it tries to allocate
a new buffer from *hci_cmd_pool*.

Should it be possible to enable scanning '*Failed to connect*'
callback? Currently
the Bluetooth central sample will simply stop if it failed to connect.
I think this should be possible. We can discuss whether the TX thread is
the right context for the controller to do the bt_recv() call from, but
meanwhile a simple solution should be to just increase the number of HCI
command buffers, i.e. set CONFIG_BT_HCI_CMD_COUNT to some higher value.

Johan


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

Li, Jun R
 

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@...> 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

 

 

3941 - 3960 of 8692