1. devel@lists.zephyrproject.org
   Date   
Re: NFC support Zephyr voor LE OOB secured pairing...

Johan Hedberg
 

Hi Frank,


On 22 Jan 2019, at 10.01, frv <@frv> wrote:

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.
Note that the APIs Rodrigo referred to are for Mesh provisioning, not for pairing. Zephyr doesn’t currently expose any OOB APIs for pairing, except bt_le_oob_get_local(), which only returns the local connectable address. I don’t think anyone would object to extending the pairing API with full OOB support however, so if you’d like to work on it the contribution would be very welcome.

Johan
Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.

Best regards,
Frank
Re: NFC support Zephyr voor LE OOB secured pairing...

Rodrigo Peixoto <rodrigopex@...>
 

Frank,
as far as I know, there are some functions that are being called during the provisioning process like "static int output_number(bt_mesh_output_action_t action, u32_t number)". This function (in my code at least) prints the OOB value for pairing. I would suggest you take a look if there are alternatives to that or maybe use this function to call your NFC tag writing one showing the OOB value to the provisioner. You can find some samples where people blink a led with the OOB value, it works as well. 

I hope it helps.

Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex




Em seg, 21 de jan de 2019 às 07:45, frv <F.Vieren@...> escreveu:

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank

Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank
Re: NFC support Zephyr voor LE OOB secured pairing...

Rodrigo Peixoto <rodrigopex@...>
 

Frank,
I have a piece of code that wakes up the MCU through NFC, but I could not write or read data from it yet. We are using only the HAL code. The only tricky is to register the interrupt with IRQ_CONNECT for avoiding spurious interrupts. Have you tried to use the HAL?

On Mon, 21 Jan 2019 at 06:07 frv <F.Vieren@...> wrote:

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank

--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.
NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank
Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi Johan,

Thanks for clarifying this one out, that is already a great relief. Honestly I'm a little bit stuck with what I want to do about security in my BLE architecture.
So far I was able to combine a number of technologies on different HW boards each running different SW stacks. 
However when trying to start implementing security I'm getting stucked. 

So what I had in mind as proof of concept for my setup:
  • On a BBB running Linux 4.20 I run a BLE central application based on QT BLE SW, connected to this BBB is a nRF52 DK running Zephyr and the hci_uart BLE connectivity stack.
  • On another nRF52 board I'm running the Zephyr  HR demo peripheral application. 
  • The BLE central application can successfully connect to the HR demo application and read out the simulated HR values.

Now I wanted to add security, so far QT BLE has not explicit way of providing this, so I'm having to do it outside the QT BLE stack (unfortunately...).
As I will not have any input or output device for verification, the idea is to implement NFC OOB unless you already say this is not an option. 

So the idea is first to tryout a setup without the NFC functionality for exchanging the data.
Thus my idea was first:
to readout the local OOB of both devices and to exchange them "manually" by running the remote oob command via the btmgmt tool of BlueZ.

However despite the SSP issue I wrongly thought needed to be set. I see that also the btmgmt complains when trying to readout de local oob data.
As mentioned in my previous post, the btmgmt throws an error saying it is not supported to Read Out Local OOB info.

So here ends my story for the moment...

Any "better" idea's how to continue from here.
Honestly I love the concept of the Zephyr BLE connectivity as it allows us to keep on the "open source" BlueZ track. Also being able to use QT for running the BLE stack is a great advantage and speeds up the development work and also the quality of the implementation.
Nevertheless also the Zephyr project is also great way to go in our BLE design we have in mind.  So keep up the good work, we love it!!! 

Thanks in advance for your help on this topic.

Best regards,
Frank

Best regards,
Frank
Re: samples: BLE Mesh : finding possibi lities to optimise onoff level lighting vnd app further ?

vikrant8051 <vikrant8051@...>
 

Hi,

I wanna clarify that Black box means implementation is based on Bluetooth Mesh specification release in 2017 but it is available in close source lib. At app level there are some limited APIs to access it & that's it.

There even it is difficult to answer
- how state binding has done ?
- how transition time related stuff has handled ?
- how data structures is designed as per Models described in various tables in specifications ?

etc. etc.

It doesn't mean what is behind that black boxes is perfect. After testing it is found that those black boxes (which are so called qualified/certified) don't even pass basic PTS test requirements :)

Zephyr own BLE & Mesh stack is robust & always gone through PTS test time to time to fulfill all its requirements. And it is only open source project which supports Bluetooth Mesh.

But those who want to build Mesh App on it could get confused if gone through specs.

So goal is to find some optimised & "standard" way to design any type of Models architecture defined in #MeshModelSpecs ( including upcoming Models under #Smarthome subgroup category).

Thanks & regards,
vikrant







On Fri 18 Jan, 2019, 12:31 PM Hedberg, Johan <johan.hedberg@... wrote:
I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan


> On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@...> wrote:
>
> Hi,  vikrant,
>
> You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
> in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.
>
>       
> wxzzzh
> wxzzzh@...
> 签名由 网易邮箱大师 定制
> On 1/17/2019 21:01，vikrant8051<vikrant8051@...> wrote：
> Hello,
>
> Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
> manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
> have implemented.
>
> So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?
>
> (Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
>  From my point of view, current implementation is pretty much stable or Okay
> & that makes me biased for it).
>
> Is there any one who has successfully implemented
> - Light HSL Server/Client models using Zephyr Mesh stack
> - which has clear all PTS test rquirements 😃
> - and have used something indigenous/superior way than proposed implementation
>    in mentioned app ? 
>
> Thanks & regards,
> vikrant
>
>

Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

Johan Hedberg
 

On 18 Jan 2019, at 21.00, Johan Hedberg <@jhe> wrote:
On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth
I meant naturally bluetoothd (stupid auto-correct :)

Johan
Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

Johan Hedberg
 

Hi,

On 18 Jan 2019, at 18.20, frv <@frv> wrote:
It seems when trying to set the SSP (Secure Simple Pairing) via the btmgmt tool I also get the error message the SSP is not supported for this adapter.
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available...

SSP is a BR/EDR feature, whereas Zephyr on Nordic MCUs only supports LE (known as a single-mode controller). So you’re not missing anything essential in this regard. The security feature in LE is called the Security Manager Protocol. On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth (it should do everything necessary for you). If you’re not running bluetooth, or for some other reason want to do things manually, you’d need to enable at least “le” and “sc” with btmgmt.

Johan
Re: BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi all, Carles,

It seems when trying to set the SSP (Secure Simple Pairing)  via the btmgmt tool  I also get the error message the SSP is not supported for this adapter. 
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available... 

Also when running the oobtest provided by the BlueZ package, the error message Secure Simple Pairing is NOT supported. Here I do the test on my Ubuntu PC which has 2 BLE adapters the internal one and the external Zephyr HCI_UART/Nordic.

Any idea what is going wrong here? 

Thanks in advance,
Best regards,
Frank
BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?

frv
 

Hi all, Carles,


During the last months I have been doing a lot of research in BLE technologies.


Finally for implementing our use case we came up with the following BLE architecture:

- a Linux embedded device (with Linux Kernel V4.20), more precise a BBB to be used as demonstrator platform before moving to a board with iMX6, running a BLE central application based on the QT BLE framework, as BLE connectivity HW, a Nordic nRF52 DK board is used that runs the RTOS Zephyr (V1.13) HCI_UART SW stack. So between both board there is a HCI_UART connection.


- as demonstrator BLE peripheral I'm using another nRF52 DK board that runs the Zephyr HR peripheral sample applic.


So the BLE central application written in QT C++, monitors the heart rate value that is simulated by the HR peripheral application. 

So far so good...


However I'm now trying to add security to the BLE architecture.

So far QT BLE doesn't explicitly implement any security  for a BLE implementation, in other words no QT API is available (yet?).


My idea is to implement  the BLE pairing outside the QT framework as it is not supported via QT.

However I'm struggling with a number of "things" and possible concepts of OOB when doing the pairing process.


I would love to implement OOB as SSP with possible NFC as method for exchanging OOB info. 


BlueZ on Linux offers a tool like btmgmt.

The idea is before starting implementing code based on this tool or the Bluetooth mgmt socket, to do some fast prototyping with this btmgmt tool in a shell.


However when I run the btmgmt local-oob, I get this output:




So it seems for some reason the HCI stack does not support this.


Could this be related to the Zephyr HCI_UART implementation?


Any help on this topic is very welcome.


More information on the "demonstrator" setup I'm trying to implement is described here:

https://bugreports.qt.io/browse/QTBUG-72989


https://forum.qt.io/topic/98427/sometimes-connection-times-out-when-trying-connecting-qt-ble-central-applic-with-ble-peripheral-applic-if-no-long-term-key-is-loaded-at-central-side
forum.qt.io
Hi, I have made a simple BLE setup between two embedded boards both with BLE connectivity. On the Beagle Bone Black with LINUX OS I run a simplified QT BLE central application that connects with a heart rate peripheral application running on a nRF52 DK b...






I would really love to stick to all these technologies (Zephyr/QT BLE/BlueZ) in our BLE design. 

The nRF52 (DK) with the Zephyr as BLE connectivity and as standalone unit for running a peripheral applic based on Zephyr is awesome.



Best regards,

Frank
Re: samples: BLE Mesh : finding possib =?utf-8?Q?i_lities_to_optimise_onoff_level_lighting_vnd_app_further_??=

wxzzzh
 

Hi, Johan,

I'm researching zephyr ble mesh too, have a questions to ask you:

In zephyr/samples/boards/nrf52/mesh/onoff-app example, use meshctl as the provisioner and configurer, is there a way to save/update the configure results in some varibles in main.c so that it's possible to send some messages to other node or group from controller side?

Thanks & Regards,

On 1/18/2019 15:01，Johan Hedberg<johan.hedberg@...> wrote：

I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan


On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@...> wrote:

Hi,  vikrant,

You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.


wxzzzh
wxzzzh@...
签名由 网易邮箱大师 定制
On 1/17/2019 21:01，vikrant8051<vikrant8051@...> wrote：
Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented.

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
in mentioned app ?  

Thanks & regards,
vikrant
Re: samples: BLE Mesh : finding possibi lities to optimise onoff level lighting vnd app further ?

Johan Hedberg
 

I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan

On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@...> wrote:

Hi, vikrant,

You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.


wxzzzh
wxzzzh@...
签名由 网易邮箱大师 定制
On 1/17/2019 21:01，vikrant8051<@vikrant8051> wrote：
Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented.

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
in mentioned app ?

Thanks & regards,
vikrant
Re: samples: BLE Mesh : finding possibi =?utf-8?Q?lities_to_optimise_onoff_level_lighting_vnd_app_further_??=

wxzzzh
 

Hi,  vikrant,

in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.
On 1/17/2019 21:01，vikrant8051<vikrant8051@...> wrote：

Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented. 

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
 From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
   in mentioned app ?  

Thanks & regards,
vikrant
Re: Deprecating and removing net-app based APIs

Paul Sokolovsky
 

Hello,

On Wed, 16 Jan 2019 18:45:34 +0200
"Jukka Rissanen" <jukka.rissanen@...> wrote:

Hi all,

I sent a PR#12506 [1] that marks these APIs as deprecated:
* net-app
* HTTP server / client
* Websocket
* SNTP

The idea is that these APIs would eventually be removed from 1.14
release.
+1 for deprecation, -1 for removal in 1.14. 1.14 is supposed to be LTS
release, and we shouldn't leave users who used prior versions of Zephyr
in the cold with the first LTS which removes a lot of familiar APIs
(even without providing replacements, as discussed below).

Over a year ago, it was agreed among network API users, that
the API to user applications would be BSD socket API interface.
Because of this various networking APIs like MQTT, CoAP and LWM2M
have been converted to use BSD socket APIs instead of net-app API.
Good. But one year isn't that big a timeframe. Some higher-level
network libs were converted to sockets, some not.

I sent a mail in the beginning of December 2018 [2] about HTTP
client/server APIs, if there would be anyone willing to maintain and
convert HTTP APIs to use BSD socket API. So far no volunteers have
been found.
Well, I responded to it with some proposals, and that's were it stands.
There should be discussion on the way to approach. It's a bit of
wishful thinking that someone will pop up at them moment that we
asked. Likewise, I'd call it a leap of faith that someone will start
to work on it just to not lose HTTP libs from Zephyr - this doesn't
guarantee quality of implementation, nor even that it'll be merged (we
had cases like "oh, you wrote something? but that's not what we
need"). Again, discussion and sustainable approach.

This removal of these APIs also means that there would
not be replacement BSD socket based APIs for HTTP, Websocket and SNTP
in 1.14.
That would be the reason to not remove them, and definitely not for
the LTS.

It is important that we do not have multiple implementations for the
same features so the old net-app based APIs need to be removed. We
will remove the duplicate (old) CoAP and MQTT API implementations as
there exists BSD socket versions for CoAP and MQTT.


Links:
[1] https://github.com/zephyrproject-rtos/zephyr/pull/12506
[2] https://lists.zephyrproject.org/g/devel/message/5537


Cheers,
Jukka
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Dev Review Meeting Agenda (Jan 17, 2019)

Kumar Gala
 

Here are the discussion items for today’s meeting, if you have any others let me know:

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Target Capabilities / Board Directory Layout Capabilities
* Include: Clean up header file namespace
* scripts/dts/extract: Generate fully qualified name define
* [DNM]Convert MCUX UART to use DT_<COMPAT> defines

- k
samples: BLE Mesh : finding possibilities to optimise onoff_level_lighting_vnd_app further ?

vikrant8051 <vikrant8051@...>
 

Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented. 

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
 From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
   in mentioned app ?  

Thanks & regards,
vikrant
Re: RFC - C99 issue regarding unnamed union/structs

Thomas Törnblom
 



Den 2019-01-16 kl. 18:31, skrev Andy Ross:

I'd also look more favorably on and be more likely to recommend
toolchains that implement broadly-used industry extensions. :)

By "broadly-used industry extensions" you mean "gcc extensions" I guess?

I did a quick test using some other C compilers I have, SunStudio 11/12, Keil uVision 5, VisualStudio 2015, and none of them accepts the "..." extension to the case labels in switch statements, at least not out of the box, so I would hardly call that "broadly-used industry extensions".

To be fair, I did find that SunStudio 12 Update 1 appears to have introduced this.

I might file an RFE for this ;)


Andy


/Thomas

--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems

Re: RFC - C99 issue regarding unnamed union/structs

Andy Ross
 

Thomas Törnblom wrote:
Would there be a problem adding a single anonymous member to this to
make it standards compliant?

After all, in C++ empty structs take up space while they don't with gcc.
And we'd never use this trick in C++ for that reason. :)

I'd personally prefer to see this done via rework that doesn't
introduce needless memory. I know I mocked it, but an
ARCH_HAS_WHATEVER kconfig really isn't an awful thing.

Note that some smarter refactoring could probably find space for this
info in other arch-defined spots that don't have this problem (like on
the stack of the caller instead of in the struct thread, which is done
for various things already and could be unified). That's getting way
beyond language standards compliance though.

Would it be OK to fix issues 1 - 4 in a PR?
I'm not the gatekeeper really, but I wouldn't object, no.

I'd also look more favorably on and be more likely to recommend
toolchains that implement broadly-used industry extensions. :)

Andy