Date   

nRF52 k_busy_wait precision

Gavrikov Paul <Paul.Gavrikov@...>
 

Hi,

I wanted to test the precision of k_busy_wait by toggling a GPIO pin and checking the output by an osciloscope. I am using a Nordic nRF52-DK2.

 

Here are my results:

TIME=1                measured=6.2us

TIME=10             measured=6.5us

TIME=50             measured=32us

TIME=200           measured=182us

What is causing this drift? Is it possible to increase the precision?

 

void main(void)

{

     struct device *dev;

     dev = device_get_binding(CONFIG_GPIO_NRF5_P0_DEV_NAME);

     gpio_pin_configure(dev, 13, GPIO_DIR_OUT);

     int cnt = 0;

     while(true) {

           gpio_pin_write(dev, 13, cnt % 2);

           cnt++;

           k_busy_wait(TIME);

     }

}

 

Best regards,

Paul Gavrikov

 

eMail: Paul.Gavrikov@...

web:  www.newtec.de

 

NewTec GmbH

Heinrich-von-Stephan-Straße 8

D-79100 Freiburg

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

 


Re: FW: support for NFFS file system

Vikrant More <vikrant8051@...>
 

Thanks for reply.

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?


On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@...> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


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


FW: support for NFFS file system

Puzdrowski, Andrzej
 

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


support for NFFS file system

Vikrant More <vikrant8051@...>
 

Hello World !!

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?
Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi Johan,

Many many thanks Johan, for your in detail explanation.

I don't want to use static public-private key pair for DEVICE & happy with current implementation.
It is inherently more secure since every time new pair get generated.

Now as per my understanding, it is only important to do authentication over OOB using randomly generated
(on every reset if DEVICE is in Unprovisioned state) 16-Bytes static-OOB.

OR

If I have to go with output-OOB or input-OOB but it will increase cost of BoM since we have to add NFC or small LCD etc. etc.
(Note that all budget smartphone doesn't have NFC feature)

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

Second point is, I don't want to use Input-OOB & output-OOB.

By taking reference from your old reply, I have an idea to generate secret RANDOM 16-bytes static OOB using DEVICE MAC address
by executing some common vendor specific algorithm on both sides where nothing will get exchanged over OOB channel.

In case of nRF52840, we get DEVICE's MAC address by accessing oob.addr.a.val.


" Static OOB or No OOB

In cases where neither Input OOB or Output OOB are possible,

the provisioner and unprovisioned device may use either Static OOB authentication or No OOB authentication.

In this case, the provisioner and unprovisioned device each generate a random number and then proceed to the check confirmation value operation "


Now this is confusing, if I edit code as follow that means only static-OOB feature is working

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,

    .static_val = static_oob,  // <-- randomly generated after every reset
    .static_val_len=16,

    //.output_size = 4,
    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    //.output_number = output_number,
    //.output_string = output_string,

    .complete = prov_complete,
    .reset = prov_reset,
};


And as per that link, if random no. is different for DEVICE & Provisioner then how they will authenticate each other

( assuming OOB channel is not at all in existence) ?

Is OOB channel is mandatory to exchange those 2 static-OOB ?

In case of #meshctl, it ask only for DEVICE's (16-bytes ) static-OOB & nothing provide from own side for DEVICE.

Is OOB channel/tunnel approx. mandatory concept of #BluetoothMesh ? 

Thank You !!

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


On Jan 17, 2018 2:15 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Jan 16, 2018, Vikrant More wrote:
> When I comment-out following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * //.output_size = 4,    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> //.output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I
> right ?

Yes.

> & when I uncomment following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * .output_size = 4,    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> .output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart follows path as per attached FlowChart_2.pdf. Am I right ?

Yes.


> DEVICE's Public key can be static or dynamic plus it can exchange over
> Bluetooth-Link or OOB. Am I right ?

Yes.

> As per current implementation, we are using *dynamic Public Key*
> *& *both sides public keys are get exchanged over Bluetooth-Link instead of
> OOB. Am I right ?

Yes.

> But when I want to use static Public-Private keys for DEVICE (provisioner
> may have dynamic pair), how & where to edit so that provisioner will
> understand that DEVICE has static public key ?

The provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.

What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.

> How provisioner will understand from where to received/read DEVICE
> public key out of *Bluetooth-Link* or *OOB* channel ?

I believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.

> If public keys get exchanged over insecure channel, then what is
> significance of OOB tunnel over Bluetooth-Link ?

You might want to read up on how Diffie-Hellman key exchange works:
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.

Johan


Re: Security of Mesh Network

Johan Hedberg
 

Hi Ashish,

On Wed, Jan 17, 2018, ashish.shukla@corvi.com wrote:
As you replied to Vikrant

"I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level)."

what if I use in-band mechanism to exchange public keys and during
authentication stage, I changed output size of OOB number to 1 and blinked
LED on the board to the same number of times. This number can be entered
into provisioner to generate ConfirmationValue.

Out of these two methods
1. 128-bit randomly generated Static OOB
2. and one I mentioned above

Which one would be more secure?
The one with higher entropy. In the example you gave it'd be some 3 bits
vs 128 bits. The main reason the Input & Output OOB mechanisms are less
secure is that there's too low entropy for the OOB data, i.e. it's too
easy to brute-force/guess it.

Johan


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Tue, Jan 16, 2018, Vikrant More wrote:
When I comment-out following lines as below

static const struct bt_mesh_prov prov =
{
.uuid = dev_uuid,


* //.output_size = 4, //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
//.output_number = output_number,*
.complete = prov_complete,
.reset = prov_reset,
};

, flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I
right ?
Yes.

& when I uncomment following lines as below

static const struct bt_mesh_prov prov =
{
.uuid = dev_uuid,


* .output_size = 4, .output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
.output_number = output_number,*
.complete = prov_complete,
.reset = prov_reset,
};

, flowchart follows path as per attached FlowChart_2.pdf. Am I right ?
Yes.


DEVICE's Public key can be static or dynamic plus it can exchange over
Bluetooth-Link or OOB. Am I right ?
Yes.

As per current implementation, we are using *dynamic Public Key*
*& *both sides public keys are get exchanged over Bluetooth-Link instead of
OOB. Am I right ?
Yes.

But when I want to use static Public-Private keys for DEVICE (provisioner
may have dynamic pair), how & where to edit so that provisioner will
understand that DEVICE has static public key ?
The provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.

What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.

How provisioner will understand from where to received/read DEVICE
public key out of *Bluetooth-Link* or *OOB* channel ?
I believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.

If public keys get exchanged over insecure channel, then what is
significance of OOB tunnel over Bluetooth-Link ?
You might want to read up on how Diffie-Hellman key exchange works:
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.

Johan


Security of Mesh Network

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

Hi Johan,

As you replied to Vikrant

"I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level)."

what if I use in-band mechanism to exchange public keys and during authentication stage, I changed output size of OOB number to 1 and blinked LED on the board to the same number of times. This number can be entered into provisioner to generate ConfirmationValue.

Out of these two methods
1. 128-bit randomly generated Static OOB
2.  and one I mentioned above

Which one would be more secure?  

 

--
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: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi Johan,

Thanks for your reply.



I've been further clearing my concept by reading above two links along with Mesh Specs.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I comment-out following lines as below

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,
    //.output_size = 4,
    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    //.output_number = output_number,

    .complete = prov_complete,
    .reset = prov_reset,
};

, flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I right ?

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

& when I uncomment following lines as below

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,
    .output_size = 4,
    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    .output_number = output_number,

    .complete = prov_complete,
    .reset = prov_reset,
};

, flowchart follows path as per attached FlowChart_2.pdf. Am I right ?

[  Here in both the cases, I'm assuming DEVICE generate dynamic public key (non OOB public key) which gets transfer over Bluetooth-LinK (non-OOB channel)
   And it is used by ECDH to calculate ECDHSecret on provisioner side ]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

DEVICE's Public key can be static or dynamic plus it can exchange over Bluetooth-Link or OOB. Am I right ?

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

As per current implementation, we are using dynamic Public Key
& both sides public keys are get exchanged over Bluetooth-Link instead of OOB. Am I right ?

But when I want to use static Public-Private keys for DEVICE (provisioner may have dynamic pair), how & where to edit so that provisioner will
understand that DEVICE has static public key ?

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

How provisioner will understand from where to received/read DEVICE public key out of Bluetooth-Link or OOB channel ?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If public keys get exchanged over insecure channel, then what is significance of OOB tunnel over Bluetooth-Link ?

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

I agree that, Bluetooth Specs has already provided details but it not easy to interpret its correct meaning


On Mon, Jan 15, 2018 at 8:42 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Mon, Jan 15, 2018, Vikrant More wrote:
> By reading this link, I understood that netKey, appKey, dveKey are
> AES-128 *symmetric
> keys* which are exchanged over encrypted *channel* during provisioning.

That's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).

> This encrypted *channel* is based on public-private keys. Provisioner has
> its combo of keys & similarly DEVICE has its own.
> And to create this channels both parties should aware of public-key of each
> other.
>
> And there are two ways to exchange public keys viz;
> 1) in-band
> 2) out-of-band (OOB) (eg. NFC, QR code )
>
> Two avoid *man-in-the-middle attacks *we should go with OOB
> *. *
>
>
> *Up till this, Am I right ?*

Yes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).

> *So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's
> private & public keys stored ? *

The ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)

> *And how to update that pair from default one ? *

Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).

> But when we enable this,
>
>     .output_size = 6,  //4
>     .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE |
> BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
>     .output_number = output_number,
>     .output_string = output_string,
>
> & we get 4 digits or 6 digits or random string on DEVICE's serial terminal,
> then what is this ? this is obviously not any type of public-key ?
> Could anybody explain me, what is going on ? What is Static OOB, Output
> OOB, Input OOB ?
>
> How Static OOB, Output OOB, Input OOB are related with the public-keys
> exchange which I've mentioned above ?

Those are steps that can happen after the public key exchange. I really
recommend you to read through section "5.4.2 Provisioning behavior" in
the Mesh Profile specification. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 5.4.2.3 is
the public key exchange, and section 5.4.2.4 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.

> If Zephyr does not have own copy of public-private keys for OOB, then how
> to generate & add them in firmware ?
> How to link them with above mentioned mechanism ?

As I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.

One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.

Johan


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Mon, Jan 15, 2018, Vikrant More wrote:
By reading this link, I understood that netKey, appKey, dveKey are
AES-128 *symmetric
keys* which are exchanged over encrypted *channel* during provisioning.
That's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).

This encrypted *channel* is based on public-private keys. Provisioner has
its combo of keys & similarly DEVICE has its own.
And to create this channels both parties should aware of public-key of each
other.

And there are two ways to exchange public keys viz;
1) in-band
2) out-of-band (OOB) (eg. NFC, QR code )

Two avoid *man-in-the-middle attacks *we should go with OOB
*. *


*Up till this, Am I right ?*
Yes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).

*So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's
private & public keys stored ? *
The ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)

*And how to update that pair from default one ? *
Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).

But when we enable this,

.output_size = 6, //4
.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE |
BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
.output_number = output_number,
.output_string = output_string,

& we get 4 digits or 6 digits or random string on DEVICE's serial terminal,
then what is this ? this is obviously not any type of public-key ?
Could anybody explain me, what is going on ? What is Static OOB, Output
OOB, Input OOB ?

How Static OOB, Output OOB, Input OOB are related with the public-keys
exchange which I've mentioned above ?
Those are steps that can happen after the public key exchange. I really
recommend you to read through section "5.4.2 Provisioning behavior" in
the Mesh Profile specification. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 5.4.2.3 is
the public key exchange, and section 5.4.2.4 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.

If Zephyr does not have own copy of public-private keys for OOB, then how
to generate & add them in firmware ?
How to link them with above mentioned mechanism ?
As I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.

One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.

Johan


Re: [BT/IPSP] Controller BT version

Erwan Gouriou
 

Hi Vinayak,

Thanks for your answer, I'll have a try on Carbon.

Erwan



On 15 January 2018 at 14:56, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Hi Erwan,

1. IPSP support requires “host” L2CAP CoC feature that was added in BT 4.2. A Controller supporting BT 4.0 shall suffice, as HOST will do L2CAP fragmentation before sending the packets to HCI controller.
2. No, Data Length feature is purely Controller. It just gives better throughput by using longer PDUs on air. As said in 1, IPSP requiring L2CAP CoC support in Host that shall suffice.

You can in the Zephyr controller (nRF5 series ) Kconfig options disable all 4.1 and above feature, and you should still be able to run IPSP, its just going to be slow on throughput without data length feature.

Regards
Vinayak


From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwan Gouriou
Sent: Monday, January 15, 2018 2:47 PM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] [BT/IPSP] Controller BT version

Hi all,
I've a question on running BT IPSP on a BT controller.

1- Which BT version should be supported by controller to be able to run IPSP sample ?
FWIU, IPSP requires 6LowPAN which only supported from BT4.2. Is that correct?

2- Though, I don't see a specific check for 4.2 supported version in hci_core code.
Is that based on LE supported features (such as LE DATA LENGHT for instance)?

Thanks
Erwan


Re: [BT/IPSP] Controller BT version

Chettimada, Vinayak Kariappa
 

Hi Erwan,

1. IPSP support requires “host” L2CAP CoC feature that was added in BT 4.2. A Controller supporting BT 4.0 shall suffice, as HOST will do L2CAP fragmentation before sending the packets to HCI controller.
2. No, Data Length feature is purely Controller. It just gives better throughput by using longer PDUs on air. As said in 1, IPSP requiring L2CAP CoC support in Host that shall suffice.

You can in the Zephyr controller (nRF5 series ) Kconfig options disable all 4.1 and above feature, and you should still be able to run IPSP, its just going to be slow on throughput without data length feature.

Regards
Vinayak


From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwan Gouriou
Sent: Monday, January 15, 2018 2:47 PM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] [BT/IPSP] Controller BT version

Hi all,
I've a question on running BT IPSP on a BT controller.

1- Which BT version should be supported by controller to be able to run IPSP sample ?
FWIU, IPSP requires 6LowPAN which only supported from BT4.2. Is that correct?

2- Though, I don't see a specific check for 4.2 supported version in hci_core code.
Is that based on LE supported features (such as LE DATA LENGHT for instance)?

Thanks
Erwan


[BT/IPSP] Controller BT version

Erwan Gouriou
 

Hi all,

I've a question on running BT IPSP on a BT controller.

1- Which BT version should be supported by controller to be able to run IPSP sample ?
FWIU, IPSP requires 6LowPAN which only supported from BT4.2. Is that correct?

2- Though, I don't see a specific check for 4.2 supported version in hci_core code.
Is that based on LE supported features (such as LE DATA LENGHT for instance)?

Thanks
Erwan


understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hello World !!

By reading this link, I understood that netKey, appKey, dveKey are AES-128 symmetric keys which are exchanged over encrypted channel during provisioning.

This encrypted channel is based on public-private keys. Provisioner has its combo of keys & similarly DEVICE has its own.
And to create this channels both parties should aware of public-key of each other.

And there are two ways to exchange public keys viz;
1) in-band
2) out-of-band (OOB) (eg. NFC, QR code )

Two avoid man-in-the-middle attacks we should go with OOB.

Up till this, Am I right ?

So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's private & public keys stored ?
And how to update that pair from default one ?

//----------------------------------------------------------------------------------------------------------------------------------------------------------------

Previously, I had asked following Question, (at that time I had forgotten to add zephyr-devel@... in CC)

//----------------------------------------------------------------------------------------------------------------------------------------------------------------


For testing I always comment-out following lines

    //.output_size = 6,
    //.output_actions = (BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING),
    //.output_number = output_number,
    //.output_string = output_string,

,otherwise I have to read that value from nRF52 terminal .

How this mechanism is going to work with actual products based on #BluetoothMesh ?

We can't ask consumer or end-user to attach device to serial terminal to get that value like we does to complete OOB-authentication procedure.

On that Mr. Johan replied as ->

In the Mesh Profile Specification, you can find the other types of input
& output OOB actions e.g. under section 5.4.1.2, in particular tables
5.22 and 5.24. The only reason the sample apps use display number/string
is that they're designed for a setup with a text-based console.

That said, the general consensus within the Mesh WG is that the
input/output OOB action mechanism is not sufficiently secure and should
only be considered to be a minor improvement over non-interactive
provisioning. The recommendation for secure provisioning is to use OOB
Public Key transfer or a 16-byte static OOB value. The actual mechanism
to do this is left up to the implementation - you can e.g. have a URL in
the node's advertising data or have a QR code printed on the node which
the provisioner reads. Using NFC is another option. IIRC, there should
be a whitepaper coming out from the Mesh WG soon which covers
recommended practices for secure provisioning.
//-------------------------------------------------------------------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------------------------------------------------------------------

But when we enable this,

    .output_size = 6,  //4
    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    .output_number = output_number,
    .output_string = output_string,

& we get 4 digits or 6 digits or random string on DEVICE's serial terminal, then what is this ? this is obviously not any type of public-key ?
Could anybody explain me, what is going on ? What is Static OOB, Output OOB, Input OOB ?

How Static OOB, Output OOB, Input OOB are related with the public-keys exchange which I've mentioned above ?

If Zephyr does not have own copy of public-private keys for OOB, then how to generate & add them in firmware ?
How to link them with above mentioned mechanism ?


Thank You !!





Re: make menuconfig does not store settings

Sebastian Boe
 

I can confirm that this is a regression from the kconfig migration.

Will fix: https://github.com/zephyrproject-rtos/zephyr/issues/5673

Thank you for reporting.
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Erwin Rol <mailinglists@erwinrol.com>
Sent: Monday, 15 January 2018 1:48:14 AM
To: Nashif, Anas; Cufi, Carles; Zephyr Devel List
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Sorry, your right. The red "Closed" button at the bottom is from the
referenced #2926 bug, that got me confused.

- Erwin


On Mon, 2018-01-15 at 00:45 +0000, Nashif, Anas wrote:
It is not closed.

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com]
Sent: Sunday, January 14, 2018 6:52 PM
To: Nashif, Anas <anas.nashif@intel.com>; Cufi, Carles <Carles.Cufi@nordicsemi.no>; Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hey Anas,

That bug report is closed, so I am a bit confused. Does that mean using menuconfig is not supported ?

- Erwin

On Sun, 2018-01-14 at 16:18 +0000, Nashif, Anas wrote:
It is not a regression, there is an old bug about this

https://github.com/zephyrproject-rtos/zephyr/issues/2907

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of
Cufi, Carles
Sent: Sunday, January 14, 2018 9:15 AM
To: Erwin Rol <mailinglists@erwinrol.com>; Zephyr Devel List
<zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


_______________________________________________
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: make menuconfig does not store settings

Erwin Rol
 

Sorry, your right. The red "Closed" button at the bottom is from the
referenced #2926 bug, that got me confused.

- Erwin

On Mon, 2018-01-15 at 00:45 +0000, Nashif, Anas wrote:
It is not closed.

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com]
Sent: Sunday, January 14, 2018 6:52 PM
To: Nashif, Anas <anas.nashif@intel.com>; Cufi, Carles <Carles.Cufi@nordicsemi.no>; Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hey Anas,

That bug report is closed, so I am a bit confused. Does that mean using menuconfig is not supported ?

- Erwin

On Sun, 2018-01-14 at 16:18 +0000, Nashif, Anas wrote:
It is not a regression, there is an old bug about this

https://github.com/zephyrproject-rtos/zephyr/issues/2907

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of
Cufi, Carles
Sent: Sunday, January 14, 2018 9:15 AM
To: Erwin Rol <mailinglists@erwinrol.com>; Zephyr Devel List
<zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


_______________________________________________
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: make menuconfig does not store settings

Nashif, Anas
 

It is not closed.

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com]
Sent: Sunday, January 14, 2018 6:52 PM
To: Nashif, Anas <anas.nashif@intel.com>; Cufi, Carles <Carles.Cufi@nordicsemi.no>; Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hey Anas,

That bug report is closed, so I am a bit confused. Does that mean using menuconfig is not supported ?

- Erwin

On Sun, 2018-01-14 at 16:18 +0000, Nashif, Anas wrote:
It is not a regression, there is an old bug about this

https://github.com/zephyrproject-rtos/zephyr/issues/2907

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of
Cufi, Carles
Sent: Sunday, January 14, 2018 9:15 AM
To: Erwin Rol <mailinglists@erwinrol.com>; Zephyr Devel List
<zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


_______________________________________________
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: make menuconfig does not store settings

Erwin Rol
 

Hey Anas,

That bug report is closed, so I am a bit confused. Does that mean using
menuconfig is not supported ?

- Erwin

On Sun, 2018-01-14 at 16:18 +0000, Nashif, Anas wrote:
It is not a regression, there is an old bug about this

https://github.com/zephyrproject-rtos/zephyr/issues/2907

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Cufi, Carles
Sent: Sunday, January 14, 2018 9:15 AM
To: Erwin Rol <mailinglists@erwinrol.com>; Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


_______________________________________________
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: make menuconfig does not store settings

Nashif, Anas
 

It is not a regression, there is an old bug about this

https://github.com/zephyrproject-rtos/zephyr/issues/2907

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Cufi, Carles
Sent: Sunday, January 14, 2018 9:15 AM
To: Erwin Rol <mailinglists@erwinrol.com>; Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] make menuconfig does not store settings

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


_______________________________________________
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: make menuconfig does not store settings

Carles Cufi
 

Hi Erwin,

This might well be a regression when we switched to kconfig.py. I will take a look with Sebastian to see what has gone wrong.

Sorry about that.

Carles

On 14/01/2018, 11:48, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Erwin Rol" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of mailinglists@erwinrol.com> wrote:

Hey All,

I have the following problem;

cd samples/net/http_server/
mkdir build
cd build
cmake .. -DBOARD=olimex_stm32_e407
make menuconfig

(select the STM32 ethernet driver )

cat zephyr/.config | grep ETH_STM32

CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_NAME="ETH_0"
CONFIG_ETH_STM32_HAL_IRQ_PRI=0
CONFIG_ETH_STM32_HAL_RX_THREAD_STACK_SIZE=1500
CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO=2
CONFIG_ETH_STM32_HAL_PHY_ADDRESS=0
CONFIG_ETH_STM32_HAL_RANDOM_MAC=y

make

cat zephyr/.config | grep ETH_STM32
(nothing)

All selections made with menuconfig are gone, from the build output I
can see make also does not build any of the needed sources. It is as if
make menufconfig was not called at all.

Am I doing something wrong here ? Or is something broken on master ?

- Erwin


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

4041 - 4060 of 8031