Date   

Re: How to run samples/subsys/usb/console on windows with nrf52840_pac10056?

Lars Knudsen
 

Hi Carles,

If the right descriptors are added, it should be possible to get working without the *.inf file.  Windows is a mess - but it *is* possible.

There seem to be something wrong in the descriptors (at least in the WebUSB sample) preventing windows from picking up the device sans drivers - but I know it is possible because I made it in this project (mbed based... trying to find time to port it over ;)) ->


(it depends on this lib that has some of the webusb support -> https://os.mbed.com/users/larsgk/code/USBDevice_WebUSB/file/1d8a6665d607/WebUSBDevice/ )

Also... remember that windows remembers devices and their drivers.. and during development/test of the solution, the easiest might be to have a clean windows VM that can be deleted on every try ... that or bump the PID ;) ... windows is ..interesting

br
Lars


On Sat, Mar 16, 2019 at 12:42 PM Cufi, Carles <carles.cufi@...> wrote:

Hi Aaron,

 

This is because Windows needs an .inf file with matching VID/PID.

Marcin from Nordic is currently working on addressing that.

 

See: https://github.com/zephyrproject-rtos/zephyr/pull/14106

 

Carles

 

From: devel@... <devel@...> On Behalf Of Aaron Xu via Lists.Zephyrproject.Org
Sent: 16 March 2019 02:10
To: zephyr-devel <zephyr-devel@...>
Cc: devel@...
Subject: [Zephyr-devel] How to run samples/subsys/usb/console on windows with nrf52840_pac10056?

 

Hi,

I want to evaluate the samples/subsys/usb/console sample. It looks quite easy from the README file. But my PC(win10) cannot recognize the USB console(I suppose CDC device) correctly.

 

PS: I connect the J3 port on pca10056 to my PC and switch the SW9 to "USB".

 

usb.png

 

Do I miss something?

Thanks.


Re: How to run samples/subsys/usb/console on windows with nrf52840_pac10056?

Carles Cufi
 

Hi Aaron,

 

This is because Windows needs an .inf file with matching VID/PID.

Marcin from Nordic is currently working on addressing that.

 

See: https://github.com/zephyrproject-rtos/zephyr/pull/14106

 

Carles

 

From: devel@... <devel@...> On Behalf Of Aaron Xu via Lists.Zephyrproject.Org
Sent: 16 March 2019 02:10
To: zephyr-devel <zephyr-devel@...>
Cc: devel@...
Subject: [Zephyr-devel] How to run samples/subsys/usb/console on windows with nrf52840_pac10056?

 

Hi,

I want to evaluate the samples/subsys/usb/console sample. It looks quite easy from the README file. But my PC(win10) cannot recognize the USB console(I suppose CDC device) correctly.

 

PS: I connect the J3 port on pca10056 to my PC and switch the SW9 to "USB".

 

usb.png

 

Do I miss something?

Thanks.


How to run samples/subsys/usb/console on windows with nrf52840_pac10056?

Aaron Xu
 

Hi,
I want to evaluate the samples/subsys/usb/console sample. It looks quite easy from the README file. But my PC(win10) cannot recognize the USB console(I suppose CDC device) correctly.

PS: I connect the J3 port on pca10056 to my PC and switch the SW9 to "USB".

usb.png

Do I miss something?
Thanks.


Zephyr v1.14.0-rc2 Tagged

Kumar Gala
 

Hi all,

We have just tagged Zephyr 1.14.0-rc2.

At this point we are freezing the code base. The focus at this point will be to close out any serious bugs and documentation issues. There will be far more scrutiny on any PR going in. Please mark any PR with the v1.14.0 milestone and either with the ‘bug’ or 'area: Documentation’.

The final release is tentatively scheduled for the 5th of April.

The full release log can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.14.0-rc2

Thanks to everybody who contributed to this release!

Kumar


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Carles Cufi
 

Hi Kai,

Hijacking the thread a bit here but have you considered using an nRF52-based board instead of the micro:bit? There's quite a few of them in really interesting form factors, including the reel_board and many others:

https://docs.zephyrproject.org/latest/boards/arm/index.html

(unfortunately I cannot filter by nRF52 but you can look around)

Carles

On 15/03/2019, 15:49, "devel@lists.zephyrproject.org on behalf of Kai Ren via Lists.Zephyrproject.Org" <devel@lists.zephyrproject.org on behalf of kren=bluetooth.com@lists.zephyrproject.org> wrote:

Hi Johan,
Thanks for the prompt reply.
I think you're expert of Zephyr Bluetooth, I have two questions before getting into the detail for optimization:
1. compiling same sample code, like sample/bluetooth/mesh/, compared with v1.12.0, do you think v1.14.0 is hungry or efficient for RAM consumption?
2. as your estimation, how many bytes will be consumed if add persistent storage?



Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@intel.com>
Sent: Friday, March 15, 2019 6:23 PM
To: Kai Ren <kren@bluetooth.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@bluetooth.com> wrote:
> I had done it, the micro:bit can be:
> 1. provisioned by nRF Mesh and meshctl through PB-GATT 2. don't
> support provisioningdata persistent storage; 3. model configuration,
> just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
> 4. don't support Proxy.
> 5. basing on Zephyr v1.12 release.
>
> I tried to put it basing on v1.14-rc1, but I think it's impossible.

I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

Hi Johan,
Thanks for the prompt reply.
I think you're expert of Zephyr Bluetooth, I have two questions before getting into the detail for optimization:
1. compiling same sample code, like sample/bluetooth/mesh/, compared with v1.12.0, do you think v1.14.0 is hungry or efficient for RAM consumption?
2. as your estimation, how many bytes will be consumed if add persistent storage?



Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@intel.com>
Sent: Friday, March 15, 2019 6:23 PM
To: Kai Ren <kren@bluetooth.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@bluetooth.com> wrote:
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT 2. don't
support provisioningdata persistent storage; 3. model configuration,
just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.
I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Johan Hedberg
 

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@bluetooth.com> wrote:
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT
2. don't support provisioningdata persistent storage;
3. model configuration, just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.
I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

Hi Johan,
I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT
2. don't support provisioningdata persistent storage;
3. model configuration, just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.


Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@intel.com>
Sent: Tuesday, March 12, 2019 10:54 PM
To: Kai Ren <kren@bluetooth.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@bluetooth.com> wrote:
This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master
following this guide and target device is
micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh
/README.html I can compile source code (the compiler is
gcc-arm-2018q4) and flash firmware into micro:bit.
But after board reset, I found that I can’t use iOS app, nRF Mesh, to
discover it. However, following this
guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/REA
DME.html

“This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=n

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?
It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Re: LE pair disconnected

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Sorry,

I also add bluetoothd file to /usr/libexec/bluetooth/

 

Thanks

Tommy

From: Tommy Lin (林志聰)
Sent: Wednesday, March 13, 2019 8:14 PM
To: 'Hedberg, Johan' <johan.hedberg@...>; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...; Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Johan,

Thanks for your information

 

I do following things:

1.     add Bluetooth.service file to /lib/systemd/system/bluetooth.service

2.     add bluetooth.conf file to /etc/dbus-1/system.d

 

and start Bluetooth service , but it is still auto disconnection after connection.

 

Could you continue to give us some suggestions

 

Thank You,

Tommy

-----Original Message-----


From: Hedberg, Johan [mailto:johan.hedberg@...]
Sent: Wednesday, March 13, 2019 4:55 PM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: Tommy Lin (
林志聰) <Tommy.Lin@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...; Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

The Linux kernel has a 2 second timeout for any connection that doesnt have users. Users in this context are e.g. any user space sockets that use the connection. Normally when bluetoothd is running it owns the ATT socket, so theres always at least one user. It sounds to me like Tommy might not have bluetoothd or any other GATT server running. Anyway, this is starting to be a bit off-topic for the Zephyr mailing list.

 

Johan

 

> On 13 Mar 2019, at 10.50, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

>

> Hi Tommy,

> Sorry, I am not able to try out your usecase on Bluez, as it has been quite sometime that I have been using with Bluez, due to my priorities, you may have to wait or ask someone else on the maillist to investigate the reasons for the host to disconnect the link.

> I am suspecting that you are not running at client that subscribes to a service, and hence the lost host decides to disconnect the idle link.

> Regards,

> Vinayak

> From: Tommy Lin (林志聰) <Tommy.Lin@...>

> Sent: 13 March 2019 08:41

> To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Vinayak,

> sorry to bother you again.

> In your experience , what reason will cause CONNECTION TERMINATED BY LOCAL HOST

> > HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                          

>         Status: Success (0x00)

>         Reason: Connection Terminated By Local Host (0x16)

> @ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                             

>         LE Address: 7A:03:05:31:E7:E6 (Resolvable)

>         Reason: Connection terminated by local host (0x02)

> <image001.png>

> Thank You,

> Tommy

> From: Tommy Lin (林志聰)

> Sent: Tuesday, March 5, 2019 11:29 AM

> To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; 'Ryan Erickson' <Ryan.Erickson@...>; 'Jamie Mccrae' <Jamie.Mccrae@...>; 'zephyr-devel@...' <zephyr-devel@...>

> Cc: 'Hanyu.Hsu@...' <Hanyu.Hsu@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Vinayak,

> btmon logs has been put in Attachment.

> Thank You.

> Tommy

> From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]

> Sent: Monday, March 4, 2019 3:50 PM

> To: Isaac Chen (陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: Re: [Zephyr-devel] LE pair disconnected

> Hi,

> Could you please provide the btmon HCI logs?

> Regards,

> Vinayak

> From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>

> Date: Monday, 4 March 2019 at 8:01 AM

> To: "Tommy Lin (林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>

> Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (徐振鋒)" <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Zephyr team,

> We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

> Best Regards

> Isaac Chen

> Quanta Computer Inc.

> Business Unit 11 BL1

> Tel  : +886-3-327-2345 Ext : 17585

> This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately.

> From: Tommy Lin (林志聰)

> Sent: Wednesday, February 27, 2019 4:03 PM

> To: Ryan Erickson; Jamie Mccrae; Isaac Chen (陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒)

> Subject: [Zephyr-devel] LE pair disconnected

>  

> Hi Ryan Erickson,

> We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

> After then , we can find out device(named 2019bt) in our phone , and we can pair it.

> But 2019bt will be disconnected after about two second at connected.

> Could you give us some suggestions

> Thank  You.

> <image002.jpg>

 


Re: LE pair disconnected

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Johan,

Thanks for your information

 

I do following things:

1.     add Bluetooth.service file to /lib/systemd/system/bluetooth.service

2.     add bluetooth.conf file to /etc/dbus-1/system.d

 

and start Bluetooth service , but it is still auto disconnection after connection.

 

Could you continue to give us some suggestions

 

Thank You,

Tommy

-----Original Message-----


From: Hedberg, Johan [mailto:johan.hedberg@...]
Sent: Wednesday, March 13, 2019 4:55 PM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: Tommy Lin (
林志聰) <Tommy.Lin@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...; Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

The Linux kernel has a 2 second timeout for any connection that doesnt have users. Users in this context are e.g. any user space sockets that use the connection. Normally when bluetoothd is running it owns the ATT socket, so theres always at least one user. It sounds to me like Tommy might not have bluetoothd or any other GATT server running. Anyway, this is starting to be a bit off-topic for the Zephyr mailing list.

 

Johan

 

> On 13 Mar 2019, at 10.50, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

>

> Hi Tommy,

> Sorry, I am not able to try out your usecase on Bluez, as it has been quite sometime that I have been using with Bluez, due to my priorities, you may have to wait or ask someone else on the maillist to investigate the reasons for the host to disconnect the link.

> I am suspecting that you are not running at client that subscribes to a service, and hence the lost host decides to disconnect the idle link.

> Regards,

> Vinayak

> From: Tommy Lin (林志聰) <Tommy.Lin@...>

> Sent: 13 March 2019 08:41

> To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Vinayak,

> sorry to bother you again.

> In your experience , what reason will cause CONNECTION TERMINATED BY LOCAL HOST

> > HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                          

>         Status: Success (0x00)

>         Reason: Connection Terminated By Local Host (0x16)

> @ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                             

>         LE Address: 7A:03:05:31:E7:E6 (Resolvable)

>         Reason: Connection terminated by local host (0x02)

> <image001.png>

> Thank You,

> Tommy

> From: Tommy Lin (林志聰)

> Sent: Tuesday, March 5, 2019 11:29 AM

> To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (陳尚航) <Isaac_Chen@...>; 'Ryan Erickson' <Ryan.Erickson@...>; 'Jamie Mccrae' <Jamie.Mccrae@...>; 'zephyr-devel@...' <zephyr-devel@...>

> Cc: 'Hanyu.Hsu@...' <Hanyu.Hsu@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Vinayak,

> btmon logs has been put in Attachment.

> Thank You.

> Tommy

> From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]

> Sent: Monday, March 4, 2019 3:50 PM

> To: Isaac Chen (陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>

> Subject: Re: [Zephyr-devel] LE pair disconnected

> Hi,

> Could you please provide the btmon HCI logs?

> Regards,

> Vinayak

> From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>

> Date: Monday, 4 March 2019 at 8:01 AM

> To: "Tommy Lin (林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>

> Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (徐振鋒)" <Ryan.Hsu@...>

> Subject: RE: [Zephyr-devel] LE pair disconnected

> Hi Zephyr team,

> We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

> Best Regards

> Isaac Chen

> Quanta Computer Inc.

> Business Unit 11 BL1

> Tel  : +886-3-327-2345 Ext : 17585

> This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately.

> From: Tommy Lin (林志聰)

> Sent: Wednesday, February 27, 2019 4:03 PM

> To: Ryan Erickson; Jamie Mccrae; Isaac Chen (陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...

> Cc: Hanyu.Hsu@...; Ryan Hsu (徐振鋒)

> Subject: [Zephyr-devel] LE pair disconnected

>  

> Hi Ryan Erickson,

> We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

> After then , we can find out device(named 2019bt) in our phone , and we can pair it.

> But 2019bt will be disconnected after about two second at connected.

> Could you give us some suggestions

> Thank  You.

> <image002.jpg>

 


Re: LE pair disconnected

Johan Hedberg
 

Hi,

The Linux kernel has a 2 second timeout for any connection that doesn’t have users. “Users” in this context are e.g. any user space sockets that use the connection. Normally when bluetoothd is running it owns the ATT socket, so there’s always at least one user. It sounds to me like Tommy might not have bluetoothd or any other GATT server running. Anyway, this is starting to be a bit off-topic for the Zephyr mailing list.

Johan

On 13 Mar 2019, at 10.50, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi Tommy,

Sorry, I am not able to try out your usecase on Bluez, as it has been quite sometime that I have been using with Bluez, due to my priorities, you may have to wait or ask someone else on the maillist to investigate the reasons for the host to disconnect the link.
I am suspecting that you are not running at client that subscribes to a service, and hence the lost host decides to disconnect the idle link.

Regards,
Vinayak

From: Tommy Lin (林志聰) <Tommy.Lin@quantatw.com>
Sent: 13 March 2019 08:41
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no>; Isaac Chen (陳尚航) <Isaac_Chen@quantatw.com>; Ryan Erickson <Ryan.Erickson@lairdtech.com>; Jamie Mccrae <Jamie.Mccrae@lairdtech.com>; zephyr-devel@lists.zephyrproject.org
Cc: Hanyu.Hsu@Avnet.com; Ryan Hsu (徐振鋒) <Ryan.Hsu@quantatw.com>
Subject: RE: [Zephyr-devel] LE pair disconnected

Hi Vinayak,
sorry to bother you again.
In your experience , what reason will cause “CONNECTION TERMINATED BY LOCAL HOST”



HCI Event: Disconnect Complete (0x05) plen 4
Status: Success (0x00)
Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8
LE Address: 7A:03:05:31:E7:E6 (Resolvable)
Reason: Connection terminated by local host (0x02)

<image001.png>

Thank You,
Tommy
From: Tommy Lin (林志聰)
Sent: Tuesday, March 5, 2019 11:29 AM
To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@nordicsemi.no>; Isaac Chen (陳尚航) <Isaac_Chen@quantatw.com>; 'Ryan Erickson' <Ryan.Erickson@lairdtech.com>; 'Jamie Mccrae' <Jamie.Mccrae@lairdtech.com>; 'zephyr-devel@lists.zephyrproject.org' <zephyr-devel@lists.zephyrproject.org>
Cc: 'Hanyu.Hsu@Avnet.com' <Hanyu.Hsu@Avnet.com>; Ryan Hsu (徐振鋒) <Ryan.Hsu@quantatw.com>
Subject: RE: [Zephyr-devel] LE pair disconnected

Hi Vinayak,
btmon logs has been put in Attachment.


Thank You.
Tommy
From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@nordicsemi.no]
Sent: Monday, March 4, 2019 3:50 PM
To: Isaac Chen (陳尚航) <Isaac_Chen@quantatw.com>; Tommy Lin (林志聰) <Tommy.Lin@quantatw.com>; Ryan Erickson <Ryan.Erickson@lairdtech.com>; Jamie Mccrae <Jamie.Mccrae@lairdtech.com>; zephyr-devel@lists.zephyrproject.org
Cc: Hanyu.Hsu@Avnet.com; Ryan Hsu (徐振鋒) <Ryan.Hsu@quantatw.com>
Subject: Re: [Zephyr-devel] LE pair disconnected

Hi,

Could you please provide the btmon HCI logs?

Regards,
Vinayak

From: "Isaac Chen (陳尚航)" <Isaac_Chen@quantatw.com>
Date: Monday, 4 March 2019 at 8:01 AM
To: "Tommy Lin (林志聰)" <Tommy.Lin@quantatw.com>, Ryan Erickson <Ryan.Erickson@lairdtech.com>, Jamie Mccrae <Jamie.Mccrae@lairdtech.com>, Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>, "zephyr-devel@lists.zephyrproject.org" <zephyr-devel@lists.zephyrproject.org>
Cc: "Hanyu.Hsu@Avnet.com" <Hanyu.Hsu@Avnet.com>, "Ryan Hsu (徐振鋒)" <Ryan.Hsu@quantatw.com>
Subject: RE: [Zephyr-devel] LE pair disconnected

Hi Zephyr team,

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?





Best Regards

Isaac Chen
Quanta Computer Inc.
Business Unit 11 BL1
Tel : +886-3-327-2345 Ext : 17585

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately.

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@lists.zephyrproject.org
Cc: Hanyu.Hsu@Avnet.com; Ryan Hsu (徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

Hi Ryan Erickson,
We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:
After then , we can find out device(named “2019bt”) in our phone , and we can pair it.
But “2019bt” will be disconnected after about two second at connected.
Could you give us some suggestions
Thank You.

<image002.jpg>


Re: Few questions regarding sockets/DTLS and net_offload

Lubos, Robert
 

Hi again,

 

  • Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

 

No, to my knowledge it is not bound to DNS in any way. This information is needed by mbedTLS to verify hostname bound to the certificate the server provides. We use it in samples where DNS is not enabled (see echo_client/server).

 

  • Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

 

This should not be an issue (unless anything got broken recently). If you suspect a lost connection, you can simply close the socket to free resources, and then create a new one.

 

Additionally, DTLS server utilizes mechanism available in mbedTLS to timeout DTLS connection – you can specify a timeout value after which DTLS connection is considered down, and DTLS resources are freed. In this case you do not need to close/reopen socket. The timeout value can be configured through Kconfig (and can be disabled as well this way). Just note, that this mechanism works only for DTLS server, not client.

 

Best regards,

Robert

 

From: Benjamin Lindqvist [mailto:benjamin.lindqvist@...]
Sent: Tuesday, March 12, 2019 17:21
To: Lubos, Robert <Robert.Lubos@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

Hi Robert,

 

Thanks for a quick response :)

 

I don't have a strong preference regarding lazy handshaking, it's probably better the way you implemented it - I'd recommend elaborating the source code comment though, because the behavior differs from the net_app API.

 

Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

 

Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

 

On Tue, Mar 12, 2019 at 5:07 PM Lubos, Robert <Robert.Lubos@...> wrote:

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin


Re: LE pair disconnected

Chettimada, Vinayak Kariappa
 

Hi Tommy,

 

Sorry, I am not able to try out your usecase on Bluez, as it has been quite sometime that I have been using with Bluez, due to my priorities, you may have to wait or ask someone else on the maillist to investigate the reasons for the host to disconnect the link.

I am suspecting that you are not running at client that subscribes to a service, and hence the lost host decides to disconnect the idle link.

 

Regards,

Vinayak

 

From: Tommy Lin (林志聰) <Tommy.Lin@...>
Sent: 13 March 2019 08:41
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Vinayak,

sorry to bother you again.

In your experience , what reason will cause CONNECTION TERMINATED BY LOCAL HOST”

 

 

 

> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                          

        Status: Success (0x00)

        Reason: Connection Terminated By Local Host (0x16)

@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                              

        LE Address: 7A:03:05:31:E7:E6 (Resolvable)

        Reason: Connection terminated by local host (0x02)

 

 

Thank You,

Tommy

From: Tommy Lin (林志聰)
Sent: Tuesday, March 5, 2019 11:29 AM
To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; 'Ryan Erickson' <Ryan.Erickson@...>; 'Jamie Mccrae' <Jamie.Mccrae@...>; 'zephyr-devel@...' <zephyr-devel@...>
Cc: 'Hanyu.Hsu@...' <Hanyu.Hsu@...>; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Vinayak,

btmon logs has been put in Attachment.

 

 

Thank You.

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 4, 2019 3:50 PM
To: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

Could you please provide the btmon HCI logs?

 

Regards,

Vinayak

 

From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>
Date: Monday, 4 March 2019 at 8:01 AM
To: "Tommy Lin (
林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>
Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (
徐振鋒)" <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Zephyr team,

 

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

 

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (
陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 


Re: LE pair disconnected

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Vinayak,

sorry to bother you again.

In your experience , what reason will cause CONNECTION TERMINATED BY LOCAL HOST”

 

 

 

> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                          

        Status: Success (0x00)

        Reason: Connection Terminated By Local Host (0x16)

@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                              

        LE Address: 7A:03:05:31:E7:E6 (Resolvable)

        Reason: Connection terminated by local host (0x02)

 

 

Thank You,

Tommy

From: Tommy Lin (林志聰)
Sent: Tuesday, March 5, 2019 11:29 AM
To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; 'Ryan Erickson' <Ryan.Erickson@...>; 'Jamie Mccrae' <Jamie.Mccrae@...>; 'zephyr-devel@...' <zephyr-devel@...>
Cc: 'Hanyu.Hsu@...' <Hanyu.Hsu@...>; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Vinayak,

btmon logs has been put in Attachment.

 

 

Thank You.

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 4, 2019 3:50 PM
To: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

Could you please provide the btmon HCI logs?

 

Regards,

Vinayak

 

From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>
Date: Monday, 4 March 2019 at 8:01 AM
To: "Tommy Lin (
林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>
Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (
徐振鋒)" <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Zephyr team,

 

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

 

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (
陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

Hi Johan,
Thank so the reply!
I got the point and I built *mesh* application basing on microbit_gatt.conf, but the compiling console told me that RAM is oversize, 104.03%.

Memory region Used Size Region Size %age Used
FLASH: 105156 B 256 KB 40.11%
SRAM: 17044 B 16 KB 104.03%
IDT_LIST: 120 B 2 KB 5.86

The compiler I used is gcc-arm-none-eabi-8-2018-q4-major.
The commit is 3aa8443ab41202f978258810961dbc5a74ad2727

By the way, could you please share that what compiler you used and the specific version?


_____________________________
Regards,
Kai




On 2019/3/12, 10:54 PM, "Hedberg, Johan" <johan.hedberg@intel.com> wrote:

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@bluetooth.com> wrote:
> This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727
>
> I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
> I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
> But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
>
> “This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”
>
> Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:
>
> CONFIG_BT_PERIPHERAL=y
> CONFIG_BT_MESH_GATT_PROXY=y
> CONFIG_BT_MESH_PB_GATT=y
> CONFIG_BT_MESH_PB_ADV=n
>
> Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Re: Few questions regarding sockets/DTLS and net_offload

Benjamin Lindqvist
 

Hi Robert,

Thanks for a quick response :)

I don't have a strong preference regarding lazy handshaking, it's probably better the way you implemented it - I'd recommend elaborating the source code comment though, because the behavior differs from the net_app API.

Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

On Tue, Mar 12, 2019 at 5:07 PM Lubos, Robert <Robert.Lubos@...> wrote:

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin


Re: Few questions regarding sockets/DTLS and net_offload

Lubos, Robert
 

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin


Few questions regarding sockets/DTLS and net_offload

Benjamin Lindqvist
 

First, regarding delayed handshakes. In sockets_tls.c:

if (net_context_get_type(ctx) == SOCK_STREAM) {
/* Do the handshake for TLS, not DTLS. */

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

Best regards,
Benjamin


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Johan Hedberg
 

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@bluetooth.com> wrote:
This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

“This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=n

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?
It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


[Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

 

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.

But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

 

This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.

 

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

 

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_MESH_GATT_PROXY=y

CONFIG_BT_MESH_PB_GATT=y

CONFIG_BT_MESH_PB_ADV=n

 

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

 

Thanks.

Kai

 

 

 

 

2241 - 2260 of 8033