Date   

Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Johan Hedberg
 

Hi,

On Wed, Mar 21, 2018, Johan Hedberg wrote:
On Wed, Mar 21, 2018, Kai Ren wrote:
Just tested it, it works well, evidence is as below. Adv address is
static even if I reset my micro:bit.

I guess this address is from Nordic chipset, NRF_FICR->DEVICEADDR,
correct?
Yes, that's correct. Could you also add a comment to the PR that you've
tested it? (this helps getting it merged quicker)

I'm also thinking of adding a new Kconfig entry (with a depends on
BT_MESH_DEBUG) which would allow you to enable this feature from the app
rather than having to hack the mesh stack's code.
I've now updated the PR with a third patch that adds this new Kconfig
option for Mesh (called CONFIG_BT_MESH_DEBUG_USE_ID_ADDR).

Johan


Re: [Zephyr-devel] How hacker will hack/impact my BLE device, when ...??

Vikrant More <vikrant8051@...>
 

Hi Vakul,

Thanks for reply !!

No, APP can't differentiate between Genuine & Fake device.

And Yes, user by mistake can connect with his neighbor/attacker Device.

solution - 1) APP will check RSSI signal strength of Device. If it is in the range of 1-2 meters then only APP proceeds further.

              2) APP will pop-up with BUTTON to force user to Blink LED on connected device. And ask user "Have you seen Blinking LED ?"
                  If he/she clicks on "YES",  then only APP proceeds further.

                  Let suppose,

                  A = attacker fake device
                  B = newly purchased User's device

                  if user by mistake connect with A, then APP will Blink A instead B. Even after this, if user click on "Yes" on response of "Have you seen Blinking LED ?"
                  then it is User responsibility.

                 Risk - In above example, User can connect with A, at same time attacker could connect with B.
                           And when user click on Button to blink LED, same time attacker may Blink LED on B. Here, user may feel that he is connected to B & will press on "YES"
                 

Regards,
vikrant8051
 



On Wed, Mar 21, 2018 at 10:38 AM, Vakul Garg <vakul.garg@...> wrote:

Hi Vikrant

 

I am curious to understand about your security implementation.

I work in area of TLS security and I am not bluetooth security expert.

 

In your case, does the app need to differentiate between a genuine or fake device?

Will it be able to create a shared secret with the device even if it is a clone of genuine device and purpose programmed to leak the common encryption key?

 

Regards

 

Vakul

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Tuesday, March 20, 2018 11:28 PM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] How hacker will hack/impact my BLE device, when ...??

 

Hi,

 

In my current project, I haven't implemented OOB pairing ( BLE based smart lights)

 

Using Zephyr built-in ECDH library, shared secret (using secp256r1 curve) get created on Device as well as on APP side which will act like encryption key for further communication.

 

On that encrypted link, APP send encryption key which is common for all devices associated with it.

 

All this happens when DEVICE is in factory reset mode.

 

There after communication link is encrypted using newly assign common key.

 

..................................................................................….........................................

 

This will create security risk, only if device is not authenticated by user & it could transfer security key ( which is common to many devices) to unauthorized device.

 

To solve this, APP will automatically trigger DEVICE's LEDs to blink & ask user "do you see blinking LED?" 

 

If user click on "YES" then & only then ECDH process will initiate & common key get share with new DEVICE.

 

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

 

Besides this I didn't found any security flaw in this implementation. So I need help from Bluetooth Security expert. Is there anyone who can help me to find out flaws & security risks in my current implementation ?

 

Thanks,

vikrant8051



Re: k_thread_user_mode_enter() usage

Vakul Garg <vakul.garg@...>
 

Hi Andrew

I am using nxp frdm_k64f (has cortex M4 core).
In my application, I have a printf() at beginning. This is causing bus fault.
Replacing it with an infinite while(1) loop hides the bus fault but stack check still remains.

Further I tried running zephyr/tests/kernel/mem_protect/userspace.
It passes successfully.

However if I introduce a printf() in function userspace/src/main.c: umode_enter_func() under the condition when is_user_context is true, it also crashes.
But here it is different exception !!

***** USAGE FAULT *****
Executing thread ID (thread): 0x200002ec
Faulting instruction address: 0x61a0
Attempt to execute undefined instruction
Caught system error -- reason 0

Further decoding faulting instruction address 0x61a0 using 'addr2line' takes me to userspace/build/frdm_k64f/zephyr/priv_stacks_hash.gperf:32
The given line number is inside following function (at the location where variable map is being dereferenced to get priv_stack_addr).

u8_t *_k_priv_stack_find(void *obj)
{
const struct _k_priv_stack_map *map =
_k_priv_stack_map_lookup((const char *)obj, sizeof(void *));
return map->priv_stack_addr;
}

I tried increasing MAIN/PREVILEDGED stack sizes in project config, but result is same.

Regards

Vakul

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie@intel.com]
Sent: Tuesday, March 20, 2018 8:16 PM
To: Vakul Garg <vakul.garg@nxp.com>; zephyr-
users@lists.zephyrproject.org
Cc: Andy Gross <andy.gross@linaro.org>
Subject: RE: k_thread_user_mode_enter() usage

It looks like you are getting two exceptions in a row.
Were you able to determine the source of the bus fault? That seems like the
real issue.
What platform is this on?

Andrew

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Vakul Garg
Sent: Tuesday, March 20, 2018 3:57 AM
To: zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] k_thread_user_mode_enter() usage

Hi

I want my application auto-launched at zephyr startup to drop its privileges
to become user mode app.
So I moved my applications entry point to app_main() and invoked it from
k_thread_user_mode_enter(app_main, NULL, NULL, NULL) from function
void main().

Now, before app_main() could get called, I get following error:

***** BUS FAULT *****
Executing thread ID (thread): 0x20002eec
Faulting instruction address: 0x12da
Precise data bus error
Address: 0x20011208
Fatal fault in thread 0x20002eec! Aborting.
***** Stack Check Fail! *****
Current thread ID = 0x20002eec
Faulting instruction address = 0x2a290

I checked that the stack sentinel check is failing in function
_check_stack_sentinel().

Can someone advise what I am doing wrong?

Regards

Vakul

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
s.zephyrproject.org%2Fmailman%2Flistinfo%2Fzephyr-
users&data=02%7C01%7Cvakul.garg%40nxp.com%7Cee6448f50f03472d438
908d58e7162a5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
6571540048549904&sdata=7%2B4eiwFRT0gglTQxGjYUNbVXu1PEoF9cp4tgK
FaIg70%3D&reserved=0


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Johan Hedberg
 

Hi Kai,

On Wed, Mar 21, 2018, Kai Ren wrote:
Just tested it, it works well, evidence is as below. Adv address is
static even if I reset my micro:bit.

I guess this address is from Nordic chipset, NRF_FICR->DEVICEADDR,
correct?
Yes, that's correct. Could you also add a comment to the PR that you've
tested it? (this helps getting it merged quicker)

I'm also thinking of adding a new Kconfig entry (with a depends on
BT_MESH_DEBUG) which would allow you to enable this feature from the app
rather than having to hack the mesh stack's code.

Johan


Re: [Zephyr-devel] How hacker will hack/impact my BLE device, when ...??

Vakul Garg <vakul.garg@...>
 

Hi Vikrant

 

I am curious to understand about your security implementation.

I work in area of TLS security and I am not bluetooth security expert.

 

In your case, does the app need to differentiate between a genuine or fake device?

Will it be able to create a shared secret with the device even if it is a clone of genuine device and purpose programmed to leak the common encryption key?

 

Regards

 

Vakul

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Tuesday, March 20, 2018 11:28 PM
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] How hacker will hack/impact my BLE device, when ...??

 

Hi,

 

In my current project, I haven't implemented OOB pairing ( BLE based smart lights)

 

Using Zephyr built-in ECDH library, shared secret (using secp256r1 curve) get created on Device as well as on APP side which will act like encryption key for further communication.

 

On that encrypted link, APP send encryption key which is common for all devices associated with it.

 

All this happens when DEVICE is in factory reset mode.

 

There after communication link is encrypted using newly assign common key.

 

..................................................................................….........................................

 

This will create security risk, only if device is not authenticated by user & it could transfer security key ( which is common to many devices) to unauthorized device.

 

To solve this, APP will automatically trigger DEVICE's LEDs to blink & ask user "do you see blinking LED?" 

 

If user click on "YES" then & only then ECDH process will initiate & common key get share with new DEVICE.

 

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

 

Besides this I didn't found any security flaw in this implementation. So I need help from Bluetooth Security expert. Is there anyone who can help me to find out flaws & security risks in my current implementation ?

 

Thanks,

vikrant8051


Firmware over the air (FOTA) and FCB support in 1.11.0

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Kai Ren <kren@...>
 

Hi Johan,

Just tested it, it works well, evidence is as below. Adv address is static even if I reset my micro:bit.

I guess this address is from Nordic chipset,  NRF_FICR->DEVICEADDR, correct?

 

Regards,

Kai

 

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@...]
Sent: Tuesday, March 20, 2018 11:05 PM
To: Kai Ren <kren@...>
Cc: Vikrant More <vikrant8051@...>; zephyr-devel@...; zephyr-users@...
Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

 

I forgot to mention that if this is for Mesh, you'd take the new option into use with something like the following:

 

--- a/subsys/bluetooth/host/mesh/adv.c

+++ b/subsys/bluetooth/host/mesh/adv.c

@@ -115,7 +115,7 @@ static inline void adv_send(struct net_buf *buf)

        ad.data_len = buf->len;

        ad.data = buf->data;

-       param.options = 0;

+       param.options = BT_LE_ADV_OPT_USE_IDENTITY;

        param.interval_min = ADV_SCAN_UNIT(adv_int);

        param.interval_max = param.interval_min;

        param.own_addr = NULL;

 

Johan

 

On Tue, Mar 20, 2018, Johan Hedberg wrote:

> Hi Kai,

>

> Here's a completely untested pull request which adds the new flag:

>

> https://github.com/zephyrproject-rtos/zephyr/pull/6720

>

> Could you try it out and let me know if it works for you?

>

> Johan

>

> On Tue, Mar 20, 2018, Kai Ren wrote:

> > Hi Johan,

> >

> > The reason I want to use static address is that it will be easy to distinguish on Bluetooth packet sniffer. Currently, if there is a Bluetooth noisy background, it's hard to trace the mesh node I'm interested in, so many adv packets pop up on packet sniffer user inferface.

> >

> > If there will be a flag to enable/disable it, it would be awesome. 

> >

> >

> > Regards,

> > Kai

> > 

> > 

> > 

> >

> > On 20/03/2018, 9:53 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

> >

> >     Hi Kai,

> >    

> >     Currently the stack will always use a non-resolvable private address

> >     when doing non-connectable advertising, regardless of what kind of

> >     privacy features are supported or not. You can see the logic related to

> >     this in the else-branch of the bt_le_adv_start() function in hci_core.c

> >     that starts on line 4728 (in the current master branch).

> >    

> >     So far there hasn't been a need to use anything else with

> >     non-connectable advertising, however if there's a good use case for this

> >     we could e.g. add a new option flag to bt_le_adv_param to force using

> >     the local identity address for advertising (I think that's what you

> >     meant instead of public address since e.g. nRF5x targets will use a

> >     static random identity address by default).

> >    

> >     Johan

> >    

> >     On Tue, Mar 20, 2018, Kai Ren wrote:

> >     > Hi Vikrant,

> >     >

> >     > Thanks for the reply.

> >     >

> >     > I tested it today, but the device address is still random. Do I need to some extra configuration for it?

> >     >

> >     > ________________________________

> >     > From: Vikrant More <vikrant8051@...>

> >     > Sent: Monday, March 19, 2018 11:09:07 AM

> >     > To: Kai Ren; zephyr-devel@...; zephyr-users@...

> >     > Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

> >     >

> >     > Hi Kai,

> >     >

> >     > In proj.conf, you can edit following config option as

> >     >

> >     > CONFIG_BT_PRIVACY=n.

> >     >

> >     > Thanks,

> >     > vikrant8051

> >     >

> >     >

> >     >

> >     >

> >     > On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@...<mailto:kren@...>> wrote:

> >     >

> >     > Hello,

> >     >

> >     > I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?

> >     >

> >     > Thanks.

> >     >

> >     >

> >     >

> >     > Regards,

> >     >

> >     > Kai

> >     >

> >     >

> >     >

> >     > _______________________________________________

> >     > Zephyr-devel mailing list

> >     > Zephyr-devel@...<mailto:Zephyr-devel@...>

> >     > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

> >    

> >     > _______________________________________________

> >     > Zephyr-devel mailing list

> >     > Zephyr-devel@...

> >     > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

> >    

> >    

> >


How hacker will hack/impact my BLE device, when ...??

Vikrant More <vikrant8051@...>
 

Hi,

In my current project, I haven't implemented OOB pairing ( BLE based smart lights)

Using Zephyr built-in ECDH library, shared secret (using secp256r1 curve) get created on Device as well as on APP side which will act like encryption key for further communication.

On that encrypted link, APP send encryption key which is common for all devices associated with it.

All this happens when DEVICE is in factory reset mode.

There after communication link is encrypted using newly assign common key.

..................................................................................….........................................

This will create security risk, only if device is not authenticated by user & it could transfer security key ( which is common to many devices) to unauthorized device.

To solve this, APP will automatically trigger DEVICE's LEDs to blink & ask user "do you see blinking LED?" 

If user click on "YES" then & only then ECDH process will initiate & common key get share with new DEVICE.

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

Besides this I didn't found any security flaw in this implementation. So I need help from Bluetooth Security expert. Is there anyone who can help me to find out flaws & security risks in my current implementation ?

Thanks,
vikrant8051


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Johan Hedberg
 

I forgot to mention that if this is for Mesh, you'd take the new option
into use with something like the following:

--- a/subsys/bluetooth/host/mesh/adv.c
+++ b/subsys/bluetooth/host/mesh/adv.c
@@ -115,7 +115,7 @@ static inline void adv_send(struct net_buf *buf)
ad.data_len = buf->len;
ad.data = buf->data;

- param.options = 0;
+ param.options = BT_LE_ADV_OPT_USE_IDENTITY;
param.interval_min = ADV_SCAN_UNIT(adv_int);
param.interval_max = param.interval_min;
param.own_addr = NULL;

Johan

On Tue, Mar 20, 2018, Johan Hedberg wrote:
Hi Kai,

Here's a completely untested pull request which adds the new flag:

https://github.com/zephyrproject-rtos/zephyr/pull/6720

Could you try it out and let me know if it works for you?

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
Hi Johan,

The reason I want to use static address is that it will be easy to distinguish on Bluetooth packet sniffer. Currently, if there is a Bluetooth noisy background, it's hard to trace the mesh node I'm interested in, so many adv packets pop up on packet sniffer user inferface.

If there will be a flag to enable/disable it, it would be awesome.


Regards,
Kai




On 20/03/2018, 9:53 PM, "Johan Hedberg" <johan.hedberg@intel.com> wrote:

Hi Kai,

Currently the stack will always use a non-resolvable private address
when doing non-connectable advertising, regardless of what kind of
privacy features are supported or not. You can see the logic related to
this in the else-branch of the bt_le_adv_start() function in hci_core.c
that starts on line 4728 (in the current master branch).

So far there hasn't been a need to use anything else with
non-connectable advertising, however if there's a good use case for this
we could e.g. add a new option flag to bt_le_adv_param to force using
the local identity address for advertising (I think that's what you
meant instead of public address since e.g. nRF5x targets will use a
static random identity address by default).

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
> Hi Vikrant,
>
> Thanks for the reply.
>
> I tested it today, but the device address is still random. Do I need to some extra configuration for it?
>
> ________________________________
> From: Vikrant More <vikrant8051@gmail.com>
> Sent: Monday, March 19, 2018 11:09:07 AM
> To: Kai Ren; zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?
>
> Hi Kai,
>
> In proj.conf, you can edit following config option as
>
> CONFIG_BT_PRIVACY=n.
>
> Thanks,
> vikrant8051
>
>
>
>
> On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:
>
> Hello,
>
> I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?
>
> Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org<mailto:Zephyr-devel@lists.zephyrproject.org>
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

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



Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Johan Hedberg
 

Hi Kai,

Here's a completely untested pull request which adds the new flag:

https://github.com/zephyrproject-rtos/zephyr/pull/6720

Could you try it out and let me know if it works for you?

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
Hi Johan,

The reason I want to use static address is that it will be easy to distinguish on Bluetooth packet sniffer. Currently, if there is a Bluetooth noisy background, it's hard to trace the mesh node I'm interested in, so many adv packets pop up on packet sniffer user inferface.

If there will be a flag to enable/disable it, it would be awesome.


Regards,
Kai




On 20/03/2018, 9:53 PM, "Johan Hedberg" <johan.hedberg@intel.com> wrote:

Hi Kai,

Currently the stack will always use a non-resolvable private address
when doing non-connectable advertising, regardless of what kind of
privacy features are supported or not. You can see the logic related to
this in the else-branch of the bt_le_adv_start() function in hci_core.c
that starts on line 4728 (in the current master branch).

So far there hasn't been a need to use anything else with
non-connectable advertising, however if there's a good use case for this
we could e.g. add a new option flag to bt_le_adv_param to force using
the local identity address for advertising (I think that's what you
meant instead of public address since e.g. nRF5x targets will use a
static random identity address by default).

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
> Hi Vikrant,
>
> Thanks for the reply.
>
> I tested it today, but the device address is still random. Do I need to some extra configuration for it?
>
> ________________________________
> From: Vikrant More <vikrant8051@gmail.com>
> Sent: Monday, March 19, 2018 11:09:07 AM
> To: Kai Ren; zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?
>
> Hi Kai,
>
> In proj.conf, you can edit following config option as
>
> CONFIG_BT_PRIVACY=n.
>
> Thanks,
> vikrant8051
>
>
>
>
> On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:
>
> Hello,
>
> I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?
>
> Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org<mailto:Zephyr-devel@lists.zephyrproject.org>
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

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



Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Kai Ren <kren@...>
 

Hi Johan,

The reason I want to use static address is that it will be easy to distinguish on Bluetooth packet sniffer. Currently, if there is a Bluetooth noisy background, it's hard to trace the mesh node I'm interested in, so many adv packets pop up on packet sniffer user inferface.

If there will be a flag to enable/disable it, it would be awesome.


Regards,
Kai




On 20/03/2018, 9:53 PM, "Johan Hedberg" <johan.hedberg@intel.com> wrote:

Hi Kai,

Currently the stack will always use a non-resolvable private address
when doing non-connectable advertising, regardless of what kind of
privacy features are supported or not. You can see the logic related to
this in the else-branch of the bt_le_adv_start() function in hci_core.c
that starts on line 4728 (in the current master branch).

So far there hasn't been a need to use anything else with
non-connectable advertising, however if there's a good use case for this
we could e.g. add a new option flag to bt_le_adv_param to force using
the local identity address for advertising (I think that's what you
meant instead of public address since e.g. nRF5x targets will use a
static random identity address by default).

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
> Hi Vikrant,
>
> Thanks for the reply.
>
> I tested it today, but the device address is still random. Do I need to some extra configuration for it?
>
> ________________________________
> From: Vikrant More <vikrant8051@gmail.com>
> Sent: Monday, March 19, 2018 11:09:07 AM
> To: Kai Ren; zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?
>
> Hi Kai,
>
> In proj.conf, you can edit following config option as
>
> CONFIG_BT_PRIVACY=n.
>
> Thanks,
> vikrant8051
>
>
>
>
> On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:
>
> Hello,
>
> I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?
>
> Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org<mailto:Zephyr-devel@lists.zephyrproject.org>
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

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


Re: k_thread_user_mode_enter() usage

Boie, Andrew P
 

It looks like you are getting two exceptions in a row.
Were you able to determine the source of the bus fault? That seems like the real issue.
What platform is this on?

Andrew

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Vakul Garg
Sent: Tuesday, March 20, 2018 3:57 AM
To: zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] k_thread_user_mode_enter() usage

Hi

I want my application auto-launched at zephyr startup to drop its privileges to become user mode app.
So I moved my applications entry point to app_main() and invoked it from k_thread_user_mode_enter(app_main, NULL, NULL, NULL) from function void main().

Now, before app_main() could get called, I get following error:

***** BUS FAULT *****
Executing thread ID (thread): 0x20002eec
Faulting instruction address: 0x12da
Precise data bus error
Address: 0x20011208
Fatal fault in thread 0x20002eec! Aborting.
***** Stack Check Fail! *****
Current thread ID = 0x20002eec
Faulting instruction address = 0x2a290

I checked that the stack sentinel check is failing in function _check_stack_sentinel().

Can someone advise what I am doing wrong?

Regards

Vakul

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


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Johan Hedberg
 

Hi Kai,

Currently the stack will always use a non-resolvable private address
when doing non-connectable advertising, regardless of what kind of
privacy features are supported or not. You can see the logic related to
this in the else-branch of the bt_le_adv_start() function in hci_core.c
that starts on line 4728 (in the current master branch).

So far there hasn't been a need to use anything else with
non-connectable advertising, however if there's a good use case for this
we could e.g. add a new option flag to bt_le_adv_param to force using
the local identity address for advertising (I think that's what you
meant instead of public address since e.g. nRF5x targets will use a
static random identity address by default).

Johan

On Tue, Mar 20, 2018, Kai Ren wrote:
Hi Vikrant,

Thanks for the reply.

I tested it today, but the device address is still random. Do I need to some extra configuration for it?

________________________________
From: Vikrant More <vikrant8051@gmail.com>
Sent: Monday, March 19, 2018 11:09:07 AM
To: Kai Ren; zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Hi Kai,

In proj.conf, you can edit following config option as

CONFIG_BT_PRIVACY=n.

Thanks,
vikrant8051




On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:

Hello,

I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?

Thanks.



Regards,

Kai



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


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Kai Ren <kren@...>
 

Hi Vikrant,

Thanks for the reply.

I tested it today, but the device address is still random. Do I need to some extra configuration for it? 


From: Vikrant More <vikrant8051@...>
Sent: Monday, March 19, 2018 11:09:07 AM
To: Kai Ren; zephyr-devel@...; zephyr-users@...
Subject: Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?
 
Hi Kai,

In proj.conf, you can edit following config option as 

CONFIG_BT_PRIVACY=n. 

Thanks,
vikrant8051




On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@...> wrote:

Hello,

I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?

Thanks.

 

Regards,

Kai

 

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


k_thread_user_mode_enter() usage

Vakul Garg <vakul.garg@...>
 

Hi

I want my application auto-launched at zephyr startup to drop its privileges to become user mode app.
So I moved my applications entry point to app_main() and invoked it from k_thread_user_mode_enter(app_main, NULL, NULL, NULL) from function void main().

Now, before app_main() could get called, I get following error:

***** BUS FAULT *****
Executing thread ID (thread): 0x20002eec
Faulting instruction address: 0x12da
Precise data bus error
Address: 0x20011208
Fatal fault in thread 0x20002eec! Aborting.
***** Stack Check Fail! *****
Current thread ID = 0x20002eec
Faulting instruction address = 0x2a290

I checked that the stack sentinel check is failing in function _check_stack_sentinel().

Can someone advise what I am doing wrong?

Regards

Vakul


Re: [Zephyr-devel] Is someone using Object Tracing?

Boie, Andrew P
 

The bookkeeping done for user mode serves a different purpose, is tightly integrated to user mode implementation and policy decisions, and its design is not optimal for the sort of IDE debugging use-cases served by object tracing. Please, let's keep them separate.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Nashif, Anas
Sent: Monday, March 19, 2018 3:06 PM
To: Pereira, Leandro <leandro.pereira@intel.com>; zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Is someone using Object Tracing?

Hi,
Yes, it is being used by a few 3rd party tools. Any object bookkeeping need to work regardless of userspace being enabled or not. Not sure about end-user impact and API changes, but that should be minimal AFAIK. You have any details on how the book-keeping is done for userspace and how it is going to be made available for non-userspace kernels?

Anas


-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Leandro Pereira
Sent: Monday, March 19, 2018 2:09 PM
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Is someone using Object Tracing?

Hi --

I've always wondered if object tracing (CONFIG_OBJECT_TRACING) was
actually used and what was the use case. I know it predates Zephyr
being open sourced, but I was unable to find code (on GitHub) referencing it. Is someone here actually using it?

The reason I'm asking this is that the bookkeeping required by the memory protection feature we're implementing over the past few releases overlaps with the one provided by this feature by quite a bit, and things could be cleaned up if it's not being used by anybody.

Granted, the user/supervisor split is not available in all platforms due to hardware requirements. But, then, is there someone that requires a runtime list of all objects of a certain type? If so, why do you need it?


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


Re: [Zephyr-devel] Is someone using Object Tracing?

Nashif, Anas
 

Hi,
Yes, it is being used by a few 3rd party tools. Any object bookkeeping need to work regardless of userspace being enabled or not. Not sure about end-user impact and API changes, but that should be minimal AFAIK. You have any details on how the book-keeping is done for userspace and how it is going to be made available for non-userspace kernels?

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Leandro Pereira
Sent: Monday, March 19, 2018 2:09 PM
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Is someone using Object Tracing?

Hi --

I've always wondered if object tracing (CONFIG_OBJECT_TRACING) was
actually used and what was the use case. I know it predates Zephyr
being open sourced, but I was unable to find code (on GitHub) referencing it. Is someone here actually using it?

The reason I'm asking this is that the bookkeeping required by the memory protection feature we're implementing over the past few releases overlaps with the one provided by this feature by quite a bit, and things could be cleaned up if it's not being used by anybody.

Granted, the user/supervisor split is not available in all platforms due to hardware requirements. But, then, is there someone that requires a runtime list of all objects of a certain type? If so, why do you need it?


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


Is someone using Object Tracing?

Leandro Pereira
 

Hi --

I've always wondered if object tracing (CONFIG_OBJECT_TRACING) was actually used and what was the use case. I know it predates Zephyr being open sourced, but I was unable to find code (on GitHub) referencing it. Is someone here actually using it?

The reason I'm asking this is that the bookkeeping required by the memory protection feature we're implementing over the past few releases overlaps with the one provided by this feature by quite a bit, and things could be cleaned up if it's not being used by anybody.

Granted, the user/supervisor split is not available in all platforms due to hardware requirements. But, then, is there someone that requires a runtime list of all objects of a certain type? If so, why do you need it?


Leandro


Re: [Zephyr-devel] Driver API conference calls

Vikrant More <vikrant8051@...>
 

Hi Carles, 
I would like to inform you that #nRF52 i2c driver is still buggy because we could read but can't write using it on I2C devices.

I've tested it using AT24Cxx EEPROM. 

Thanks,
vikrant8051

On Mon, Mar 19, 2018, 7:48 PM Cufi, Carles <Carles.Cufi@...> wrote:
Hi all,

The driver API calls take place on Tuesdays at 17h CET (9h PST) with the goal of improving and freezing those APIs while covering the requirements of all the hardware currently supported by Zephyr.

Below you can find the targets for the two next upcoming calls along with a list of required attendees and the link to join the calls.

Target for the 20th of March:

Required to attend: Tomasz B., Andrzej G., Maureen H., Yannis D.

* Close and freeze the SPI Master API (https://github.com/zephyrproject-rtos/zephyr/pull/5921)
* Close and freeze SPI slave proposal from Tomasz (https://github.com/zephyrproject-rtos/zephyr/pull/5921)

Target for the 27th of March:

Required to attend: Tomasz B., Andrzej G., Maureen H.
Optional: Martí B.

* Discuss the Watchdog API (https://github.com/zephyrproject-rtos/zephyr/pull/1260)
  * Requires at least 1 implementation
* Discuss the ADC proposal from Andrzej (https://github.com/zephyrproject-rtos/zephyr/pull/6176)

Join via: https://zoom.us/j/177647878

Regards,

Carles

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


Re: [Zephyr-devel] Is it allowed to use public Bluetooth device address instead of non-resolvable random device address in the project of /sample/bluetooth/mesh_deom?

Vikrant More <vikrant8051@...>
 

Hi Kai,

In proj.conf, you can edit following config option as 

CONFIG_BT_PRIVACY=n. 

Thanks,
vikrant8051




On Mon, Mar 19, 2018, 8:16 AM Kai Ren <kren@...> wrote:

Hello,

I’m using micro:bit to run /sample/bluetooth/mesh_demo/, I found that it use non-resolvable random device address, I’d like to make it use public Bluetooth device address (it’s easy to distinguish on Bluetooth packet sniffer), it is allowed to do? How can I configure it in the ./mesh_demo/ project?

Thanks.

 

Regards,

Kai

 

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

2061 - 2080 of 2697