devel@lists.zephyrproject.org

Zephyr Toolchain Working Group Meeting – 16 November 2020

Rasmussen, Torsten

#7458

Call for today’s Toolchain WG.

Agenda

Updates:

Thomas: IAR: Updates ?
Zephyr SDK.

LLVM support

compiler-rt.

LLVM toolchain – arm updates
Milestones for 2.5, news.

Feel free to send a mail, if you would like additional topics to be discussed.

Best regards

Torsten T. Rasmussen

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 682 738 030#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

Re: RISC-V maintainers and collaborators

Katsuhiro Suzuki

#7457

Hello Maureen-san,

Sorry for late, I created PR 30033 that just adds
myself to collaborators.

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

Best Regards,
Katsuhiro Suzuki

Show quoted text

On 2020/11/12 5:28, Maureen Helm (OSS) wrote:
Hi Suzuki-san,
Yes, please create a pull request. MAINTAINERS.yml is at the top of the main zephyr tree.
Maureen
-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: Wednesday, November 11, 2020 9:41 AM
To: Maureen Helm (OSS) <maureen.helm@oss.nxp.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] RISC-V maintainers and collaborators
Hello Maureen,
I want to join as collaborators.
Would you tell me how to add? By pull request?
Best Regards,
Katsuhiro Suzuki
On 2020/11/10 5:52, Maureen Helm wrote:
Hi everyone,
We are looking for collaborators and maintainers to help maintain the RISC-V architecture in Zephyr, and have several major RISC-V pull requests (SMP and memory protection) in acute need of code review. If you are interested in taking on one of these important roles and helping to advance RISC-V support in Zephyr, I encourage you to review the TSC Project Roles [1], start reviewing RISC-V pull requests [2], and consider adding yourself as a collaborator in MAINTAINERS.yml. Active collaborators are encouraged to become maintainers with TSC approval.

[1] https://docs.zephyrproject.org/latest/contribute/project_roles.html
[2] https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+label%3A%22area%3A+RISCv32%2F64%22

Maureen

new facility for formatted output

Peter A. Bigot

#7456

With the merge of https://github.com/zephyrproject-rtos/zephyr/pull/29876 Zephyr printk, shell_printf, minimal libc sprintf, and some other in-tree facilities use a common formatting functionality that supports almost everything in C18 *printf, with Kconfig options to reduce the code size impact based on controlling feature availability. That PR added a C99 stdio value formatter capability named cbprintf() (plus related variants) where generated text is emitted through a callback. This allows generation of arbitrarily long output without a buffer, functionality that is core to printk, logging, and other system and application needs. The formater supports most C99 specifications, excluding:

%L[aefg] long double conversion
wide character output

The new solution is derived from z_prf(), which had the most complete functionality available. Format parsing has been reimplemented, while floating point conversion has been retained and enhanced.
Kconfig options allow disabling features like floating-point conversion if they are not necessary. Benefits include:No more inconsistencies between printk, logging, and shell formatting capabilities.

Reduced inconsistencies due to toolchain libc capabilities.
Simplified (toolchain-independent) formatting feature selection via Kconfig.
Core infrastructure can avoid duplication with libc printf by using cbprintf variants.
Potentially a path to resolving #18351 and related issues, as the infrastructure can tell a caller the total size of arguments to the conversion string.
Fixed bugs with several specifications.

Costs include:

Applications that used only printk with no extra features consume more code space than the previous implementation.

More information is available at: https://docs.zephyrproject.org/latest/reference/misc/formatted_output.html You may see either an increase or a decrease in code size depending on what your application uses. Some code size can be reduced by switching in-tree use of snprintf to snprintfcb to avoid pulling in libc formatters. I expect there'll be a burn-in period while we identify Kconfig settings that have to change to maintain compatibility. Please mention me (@pabigot) in any issues or slack questions that you have about this. Peter

Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 12 November 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>

#7455

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 12 November 2020
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 483 314 739#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

Calendar

Re: RISC-V maintainers and collaborators

Maureen Helm

#7454

Hi Suzuki-san,
Yes, please create a pull request. MAINTAINERS.yml is at the top of the main zephyr tree.

Maureen

Show quoted text

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: Wednesday, November 11, 2020 9:41 AM
To: Maureen Helm (OSS) <maureen.helm@oss.nxp.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] RISC-V maintainers and collaborators

Hello Maureen,

I want to join as collaborators.
Would you tell me how to add? By pull request?

Best Regards,
Katsuhiro Suzuki

On 2020/11/10 5:52, Maureen Helm wrote:
Hi everyone,
We are looking for collaborators and maintainers to help maintain the RISC-V architecture in Zephyr, and have several major RISC-V pull requests (SMP and memory protection) in acute need of code review. If you are interested in taking on one of these important roles and helping to advance RISC-V support in Zephyr, I encourage you to review the TSC Project Roles [1], start reviewing RISC-V pull requests [2], and consider adding yourself as a collaborator in MAINTAINERS.yml. Active collaborators are encouraged to become maintainers with TSC approval.

[1] https://docs.zephyrproject.org/latest/contribute/project_roles.html
[2] https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+label%3A%22area%3A+RISCv32%2F64%22

Maureen

Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 26 November 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>

#7453

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 26 November 2020
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 483 314 739#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

Calendar

Re: RISC-V maintainers and collaborators

Katsuhiro Suzuki

#7452

Hello Maureen,

I want to join as collaborators.
Would you tell me how to add? By pull request?

Best Regards,
Katsuhiro Suzuki

Show quoted text

On 2020/11/10 5:52, Maureen Helm wrote:
Hi everyone,
We are looking for collaborators and maintainers to help maintain the RISC-V architecture in Zephyr, and have several major RISC-V pull requests (SMP and memory protection) in acute need of code review. If you are interested in taking on one of these important roles and helping to advance RISC-V support in Zephyr, I encourage you to review the TSC Project Roles [1], start reviewing RISC-V pull requests [2], and consider adding yourself as a collaborator in MAINTAINERS.yml. Active collaborators are encouraged to become maintainers with TSC approval.
[1] https://docs.zephyrproject.org/latest/contribute/project_roles.html
[2] https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+label%3A%22area%3A+RISCv32%2F64%22
Maureen

Re: #LWM2M #Leshan #QEMU #Networking #lwm2m #leshan #qemu #networking

Khaled Elsayed

#7451

Seems like a problem in the local host 192.168.0.20. Could you route any traffic from another local machine (not Qemu) via that host, i.e. set 192.168.0.20 as their G/W? Also are you able to ping from Qemu to 192.168.0.1 (I assume not, but just trying to localize where the problem is).

Also make sure you issue these commands as root on 192.168.0.20.

Show quoted text

On Tue, Nov 10, 2020 at 7:13 PM Thomas LE ROUX <thomas.leroux@...> wrote:

Hi everybody !

I'm trying to build a projet using Zephyr & LWM2M (& Leshan).

For now, I’m prototyping on QEMU.

TL;DR before explaining more precisely my issue : There must be a way to connect a QEMU instance to a remote server, but I’m stuck trying to do this.
—

I have made my small application to test things out, and except Firmware Update (my previous mail), everything is working fine on a local scale.

Running my client & Leshan server on the server along with the loop-socat and loop-slip-tap scripts given on /tools/net-tools/ causes no issue.

(Procedure followed here : https://docs.zephyrproject.org/latest/guides/networking/qemu_setup.html).

I’d like to connect my client to a Leshan server running on an AWS EC2 Instance.

I have made a small schematic. The goal would be to connect my Client (aka QEMU) to the Leshan server running on the Instance.
From the QEMU instance, I am able to run small commands. One of them is « net ping xxx ». From my client, I am able to ping the local Leshan and my computer. The ping request direct to other peripherals (other computers, my Internet modem, remote Leshan …) all end up in a timeout.

From my computer, I am able to ping basically anyone on the network.

I have followed the tutorial (given here : https://docs.zephyrproject.org/latest/guides/networking/qemu_setup.html#setting-up-zephyr-and-nat-masquerading-on-host-to-access-internet), and added to my prj.conf : CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.0.20".

Running the following commands didn’t raise any error message, so I assume that eveything went right :
iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.0.2.1
sysctl -w net.ipv4.ip_forward=1
I used Zenmap, a GUI tool for Nmap and here is my network’s map. Center point is my internet modem (choose this for a viewing perspective.) The long blue line going up is the route for reaching my EC2 instance. It confirms that my computer can reach anything, but only my computer can reach 192.0.2.1.

I used Wireshark on the tap0 interface generated by loop-slip-tap.sh and it seems that the registration’s frame sent to the EC2 instance stays on the tap0 interface and never leaves my computer.

I think the issue might be related to the use of those 2 scripts but I’m not sure and I’m (clearly) not the best in terms of networking.

My problem is pretty much described, if needed, I can send some logs.

Thank you for your help !

Best regards,

Thomas

--

Khaled Elsayed

Technical Fellow

Si-Vision LLC

Square 1142, Al Ezaei Salah Zaki St.,

Sheraton Heliopolis,

Cairo, 11361 EGYPT

Mob. +(20)100 1649292

The information contained in this message is privileged, confidential or otherwise protected from use and disclosure. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying or dissemination of this message or the taking of any action in reliance on its contents, or other use is strictly prohibited. If you received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.

Si-Vision, LLC.

#LWM2M #Leshan #QEMU #Networking #lwm2m #leshan #qemu #networking

Thomas LE ROUX

#7450

Hi everybody !

I'm trying to build a projet using Zephyr & LWM2M (& Leshan).

For now, I’m prototyping on QEMU.

TL;DR before explaining more precisely my issue : There must be a way to connect a QEMU instance to a remote server, but I’m stuck trying to do this.

—

I have made my small application to test things out, and except Firmware Update (my previous mail), everything is working fine on a local scale.

Running my client & Leshan server on the server along with the loop-socat and loop-slip-tap scripts given on /tools/net-tools/ causes no issue.

(Procedure followed here : https://docs.zephyrproject.org/latest/guides/networking/qemu_setup.html).

I’d like to connect my client to a Leshan server running on an AWS EC2 Instance.

I have made a small schematic. The goal would be to connect my Client (aka QEMU) to the Leshan server running on the Instance.

From the QEMU instance, I am able to run small commands. One of them is « net ping xxx ». From my client, I am able to ping the local Leshan and my computer. The ping request direct to other peripherals (other computers, my Internet modem, remote Leshan …) all end up in a timeout.

From my computer, I am able to ping basically anyone on the network.

I have followed the tutorial (given here : https://docs.zephyrproject.org/latest/guides/networking/qemu_setup.html#setting-up-zephyr-and-nat-masquerading-on-host-to-access-internet), and added to my prj.conf : CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.0.20".

Running the following commands didn’t raise any error message, so I assume that eveything went right :

iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.0.2.1
```
sysctl -w net.ipv4.ip_forward=1
```

I used Zenmap, a GUI tool for Nmap and here is my network’s map. Center point is my internet modem (choose this for a viewing perspective.) The long blue line going up is the route for reaching my EC2 instance. It confirms that my computer can reach anything, but only my computer can reach 192.0.2.1.

I used Wireshark on the tap0 interface generated by loop-slip-tap.sh and it seems that the registration’s frame sent to the EC2 instance stays on the tap0 interface and never leaves my computer.

I think the issue might be related to the use of those 2 scripts but I’m not sure and I’m (clearly) not the best in terms of networking.

My problem is pretty much described, if needed, I can send some logs.

Thank you for your help !

Best regards,

Thomas

Zephyr Project: APIs - Tue, 11/10/2020 5:00pm-6:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>

#7449

Reminder: Zephyr Project: APIs

When: Tuesday, 10 November 2020, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 317 990 129#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

RISC-V maintainers and collaborators

Maureen Helm

#7448

Hi everyone,

We are looking for collaborators and maintainers to help maintain the RISC-V architecture in Zephyr, and have several major RISC-V pull requests (SMP and memory protection) in acute need of code review. If you are interested in taking on one of these important roles and helping to advance RISC-V support in Zephyr, I encourage you to review the TSC Project Roles [1], start reviewing RISC-V pull requests [2], and consider adding yourself as a collaborator in MAINTAINERS.yml. Active collaborators are encouraged to become maintainers with TSC approval.

[1] https://docs.zephyrproject.org/latest/contribute/project_roles.html

[2] https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+label%3A%22area%3A+RISCv32%2F64%22

Maureen

API meeting: agenda

Carles Cufi

#7447

Hi all,

Agenda for tomorrow.

- API and component naming conventions 
  - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/29569

- New cbprintf family of functions:
  - PR: https://github.com/zephyrproject-rtos/zephyr/pull/29876

and then, time permitting we'd like to follow-up on pinctrl (the Thursday dev-review meeting also deals with this subject in a regular basis):

 - Pinmux and pinctrl API: Decide what the priorities for this are, and how to get to LTS with it
   - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Re: Question about the sanitycheck for SMP

Katsuhiro Suzuki

#7446

Hello Andrew,

Thanks for comments.

On 2020/11/09 16:08, Boie, Andrew P wrote:
    - Sometimes success/fault on my RISC-V SMP environment
      At first, I think it's bug of my patches, but...
    - Also same tests sometimes success/fault on qemu_x86_64There are known issues with SMP and Zephyr's scheduler:
https://github.com/zephyrproject-rtos/zephyr/issues/28105
Andrew
I understand you are fixing the problem.

Currently we cannot trust sanitycheck results for SMP.
And in last month, you told me there are no active maintainer
in RISC-V area.

So I wonder how to proceed merging SMP support for RISC-V...

Best Regards,
Katsuhiro Suzuki

Re: Question about the sanitycheck for SMP

Boie, Andrew P

#7445

   - Sometimes success/fault on my RISC-V SMP environment
     At first, I think it's bug of my patches, but...
   - Also same tests sometimes success/fault on qemu_x86_64There are known issues with SMP and Zephyr's scheduler:

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

Andrew

Question about the sanitycheck for SMP

Katsuhiro Suzuki

#7444

Hello,

I'm continuing to try and fix bugs of SMP support for RISC-V.
My first target is my patches pass the 'sanitycheck' and 'buildkite'
tests.

I'm facing strange behavior of sanitycheck currently:

  - Sometimes success/fault on my RISC-V SMP environment
    At first, I think it's bug of my patches, but...
  - Also same tests sometimes success/fault on qemu_x86_64

For example this is result of tests/kernel/mem_protect/sys_sem/
(Using SDK-0.11.4)

----------------------------------------
$ cmake -G Ninja -DBOARD=qemu_x86_64 ../tests/kernel/mem_protect/sys_sem/

$ ninja run
[3/4] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: qemu64,+x2apic
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EC
X.x2apic [bit 21]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
SeaBIOS (version rel-1.12.1-0-ga5cab58-dirty-20200625_115407-9426dddc0a1f-zephyr
)
Booting from ROM..*** Booting Zephyr OS build zephyr-v2.4.0-1318-g73e8cadbb398  ***
Running test suite test_sys_sem
===================================================================
START - test_basic_sem_test
 PASS - test_basic_sem_test
===================================================================
START - test_simple_sem_from_isr
 PASS - test_simple_sem_from_isr
===================================================================
START - test_sem_take_timeout_isr
 PASS - test_sem_take_timeout_isr
===================================================================
START - test_sem_give_take_from_isr
 PASS - test_sem_give_take_from_isr
===================================================================
START - test_simple_sem_from_task
 PASS - test_simple_sem_from_task
===================================================================
START - test_sem_take_no_wait
 PASS - test_sem_take_no_wait
===================================================================
START - test_sem_take_no_wait_fails
 PASS - test_sem_take_no_wait_fails
===================================================================
START - test_sem_take_timeout_fails
 PASS - test_sem_take_timeout_fails
===================================================================
START - test_sem_take_timeout

    Assertion failed at ZEPHYR_BASE/tests/kernel/mem_protect/sys_sem/src/main.c:277: test_sem_take_timeout: (ret_value == 0 is false)
sys_sem_take failed when its shouldn't have
 FAIL - test_sem_take_timeout
===================================================================
START - test_sem_take_timeout_forever
 PASS - test_sem_take_timeout_forever
===================================================================
START - test_sem_take_multiple
 PASS - test_sem_take_multiple
===================================================================
START - test_sem_give_limit
 PASS - test_sem_give_limit
===================================================================
START - test_sem_multiple_threads_wait
 PASS - test_sem_multiple_threads_wait
===================================================================
Test suite test_sys_sem failed.
----------------------------------------

Current test set and results are correct? Or is there any bugs or
limitations of current sanitycheck? I'm not sure. If you have any
ideas or reasons, please tell me.

Best Regards,
Katsuhiro Suzuki

Zephyr Project: Dev Meeting - Thu, 11/05/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>

#7443

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 5 November 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 483 314 739#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

Dev-Review Meeting Agenda Nov 5th

Kumar Gala

#7442

Here’s the agenda topics for this week:

As I send this there are no topics listed with dev-review tag, so no specific agenda topic items.  However, since the API meeting didn’t have time to discuss pinmux/pinctrl we will pick that topic this week.

* Any PR/issues w/dev-review tag

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

* Pinmux and pinctrl API: Decide what the priorities for this are, and how to get to LTS with it

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

- k

Zephyr Project: APIs - Tue, 11/03/2020 5:00pm-6:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>

#7441

Reminder: Zephyr Project: APIs

When: Tuesday, 3 November 2020, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 317 990 129#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

Zephyr: Networking Forum - Tue, 11/03/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>

#7440

Reminder: Zephyr: Networking Forum

When: Tuesday, 3 November 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: tsc@...

Description:

Live Agenda/Minutes: https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

Shared Folder:
https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

________________________________________________________________________________

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 458 216 365#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

Re: Bluez' mesh-cfgclient fails to retrieve composition data from onoff-app sample

Trond Snekvik

#7439

That's good to hear, thanks for confirming.

Trond

Show quoted text

From: Steve Brown <sbrown@...>
Sent: Tuesday, November 3, 2020 10:59
To: Snekvik, Trond <Trond.Einar.Snekvik@...>; zephyr-devel@... <zephyr-devel@...>
Subject: Re: Bluez' mesh-cfgclient fails to retrieve composition data from onoff-app sample

Hi Trond,

On further testing, it now works.

I must have not properly flashed my board.

Sorry for the noise and thanks for the fix.

Steve

On Tue, 2020-11-03 at 08:21 +0000, Snekvik, Trond wrote:
> Hi,
>
> Looks like this is caused by a discrepancy between what MIC length
> was passed into the encryption function and packet assembly when the
> MIC length is 8 (which just happens in segmented messages).
>
> I have made PR:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F29739&data=04%7C01%7CTrond.Einar.Snekvik%40nordicsemi.no%7C3e56da8edf5a40e8722908d87fdf281a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637399944054389517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9AyTQRjqqyA50x6ElnFbQN1gyOj8c1a5fxGXV4%2FOEOM%3D&reserved=0
>
> Please test it and provide feedback if you can.
>
> Thanks for the detailed bug report!
>
> Trond
>
> From: Steve Brown <sbrown@...>
> Sent: Monday, November 2, 2020 18:13
> To: zephyr-devel@... <
> zephyr-devel@...>
> Cc: Snekvik, Trond <Trond.Einar.Snekvik@...>
> Subject: Bluez' mesh-cfgclient fails to retrieve composition data
> from onoff-app sample
>
> I bisected this to eca014115
> Bluetooth: Mesh: Isolate cryptographic material
>
> I suspect segmented messages. The successful sequence number starts
> at
> 2 whereas the failing one starts at 1.
>
> I'm not familiar enough with the code to go further than this.
>
> Nothing appears in the meshd debug log with the failing case.
>
> Provisioning succeeds and configuration commands that return
> unsegmented messages, like ttl-get, work.
>
> Steve
>
> FAILING TRACE
> [00:00:44.745,727] <dbg> bt_mesh_access.model_send: net_idx 0x0000
> app_idx 0xfffe dst 0x0001
> [00:00:44.745,758] <dbg> bt_mesh_access.model_send: len 50:
> 0200f105000000000a0003000000050~
> [00:00:44.745,788] <dbg> bt_mesh_transport.bt_mesh_trans_send:
> net_idx 0x0000 app_idx 0xfffe dst 0x0001
> [00:00:44.745,819] <dbg> bt_mesh_transport.bt_mesh_trans_send: len
> 50: 0200f105000000000a0003000000050~
> [00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: src 0x0116 dst
> 0x0001 app_idx 0xfffe aszmic 1 sdu_len 54
> [00:00:44.745,971] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0001
> (segs: 5)
> [00:00:44.746,002] <dbg> bt_mesh_transport.send_seg: seg 0:
> 581b6de7e895153634729e5a
> [00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 1:
> 78298189c7f317ef0d1bf4c0
> [00:00:44.746,032] <dbg> bt_mesh_transport.send_seg: seg 2:
> 3def2b3f3ff14af374b4cda1
> [00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 3:
> ce9fa72cb97cf05f4986433d
> [00:00:44.746,063] <dbg> bt_mesh_transport.send_seg: seg 4:
> b4e6c4dc7c54
> [00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> SeqZero: 0x0001 Attempts: 4
> [00:00:44.746,093] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 0/4
> [00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 80800404581b6de7e895153634729e5~
> [00:00:44.746,124] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000001
> [00:00:44.746,154] <dbg> bt_mesh_net.net_header_encode: src 0x0116
> dst 0x0001 ctl 0 seq 0x000001
> [00:00:44.746,307] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 1/4
> [00:00:44.746,307] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 8080042478298189c7f317ef0d1bf4c~
> [00:00:44.746,337] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
> [00:00:44.746,337] <dbg> bt_mesh_net.net_header_encode: src 0x0116
> dst 0x0001 ctl 0 seq 0x000002
> [00:00:44.746,490] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 2/4
> [00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:44.746,520] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 808004443def2b3f3ff14af374b4cda~
> [00:00:44.746,551] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
> [00:00:44.746,551] <dbg> bt_mesh_net.net_header_encode: src 0x0116
> dst 0x0001 ctl 0 seq 0x000003
> [00:00:44.746,704] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 3/4
> [00:00:44.746,704] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 80800464ce9fa72cb97cf05f4986433~
> [00:00:44.746,734] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
> [00:00:44.746,765] <dbg> bt_mesh_net.net_header_encode: src 0x0116
> dst 0x0001 ctl 0 seq 0x000004
> [00:00:44.746,917] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 4/4
> [00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x0116 dst
> 0x0001 len 10 headroom 9 tailroom 10
> [00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 10: <log_strdup alloc failed>
> [00:00:44.746,917] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
> [00:00:44.746,948] <dbg> bt_mesh_net.net_header_encode: src 0x0116
> dst 0x0001 ctl 0 seq 0x000005
>
> SUCCESS
> [00:00:50.364,929] <dbg> bt_mesh_cfg_srv.dev_comp_data_get: net_idx
> 0x0000 app_idx 0xfffe src 0x0001 len 1: 00
> [00:00:50.364,959] <dbg> bt_mesh_access.model_send: net_idx 0x0000
> app_idx 0xfffe dst 0x0001
> [00:00:50.364,990] <dbg> bt_mesh_access.model_send: len 50:
> 0200f105000000000a0003000000050~
> [00:00:50.364,990] <dbg> bt_mesh_transport.bt_mesh_trans_send:
> net_idx 0x0000 app_idx 0xfffe dst 0x0001
> [00:00:50.365,051] <dbg> bt_mesh_transport.bt_mesh_trans_send: len
> 50: 0200f105000000000a0003000000050~
> [00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: src 0x011a dst
> 0x0001 app_idx 0xfffe aszmic 1 sdu_len 58
> [00:00:50.365,203] <dbg> bt_mesh_transport.send_seg: SeqZero 0x0002
> (segs: 5)
> [00:00:50.365,234] <dbg> bt_mesh_transport.send_seg: seg 0:
> 0c0139ab229a128ab4d9da66
> [00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 1:
> 7911abbd986ab5cc2ba3a7fd
> [00:00:50.365,264] <dbg> bt_mesh_transport.send_seg: seg 2:
> b9460beeec1aca3c73012043
> [00:00:50.365,295] <dbg> bt_mesh_transport.send_seg: seg 3:
> 254d22b179271b62687efbed
> [00:00:50.365,325] <dbg> bt_mesh_transport.send_seg: seg 4:
> 6c7b29d675eb290476cd
> [00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> SeqZero: 0x0002 Attempts: 4
> [00:00:50.365,325] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 0/4
> [00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:50.365,356] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 808008040c0139ab229a128ab4d9da6~
> [00:00:50.365,386] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000002
> [00:00:50.365,386] <dbg> bt_mesh_net.net_header_encode: src 0x011a
> dst 0x0001 ctl 0 seq 0x000002
> [00:00:50.365,539] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 1/4
> [00:00:50.365,539] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 808008247911abbd986ab5cc2ba3a7f~
> [00:00:50.365,570] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000003
> [00:00:50.365,600] <dbg> bt_mesh_net.net_header_encode: src 0x011a
> dst 0x0001 ctl 0 seq 0x000003
> [00:00:50.365,722] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 2/4
> [00:00:50.365,753] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: 80800844b9460beeec1aca3c7301204~
> [00:00:50.365,783] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000004
> [00:00:50.365,783] <dbg> bt_mesh_net.net_header_encode: src 0x011a
> dst 0x0001 ctl 0 seq 0x000004
> [00:00:50.365,936] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 3/4
> [00:00:50.365,936] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst
> 0x0001 len 16 headroom 9 tailroom 4
> [00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 16: <log_strdup alloc failed>
> [00:00:50.365,966] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000005
> [00:00:50.365,966] <dbg> bt_mesh_net.net_header_encode: src 0x011a
> dst 0x0001 ctl 0 seq 0x000005
> [00:00:50.366,119] <dbg> bt_mesh_transport.seg_tx_send_unacked:
> Sending 4/4
> [00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x011a dst
> 0x0001 len 14 headroom 9 tailroom 6
> [00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len
> 14: <log_strdup alloc failed>
> [00:00:50.366,149] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x000006
> [00:00:50.366,149] <dbg> bt_mesh_net.net_header_encode: src 0x011a
> dst 0x0001 ctl 0 seq 0x000006
>
>