Date   

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

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

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:

________________________________________________________________________________
+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
 

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@...>
 

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


________________________________________________________________________________
+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@...>
 

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:


________________________________________________________________________________
+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
 

That's good to hear, thanks for confirming.

Trond


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&amp;data=04%7C01%7CTrond.Einar.Snekvik%40nordicsemi.no%7C3e56da8edf5a40e8722908d87fdf281a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637399944054389517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9AyTQRjqqyA50x6ElnFbQN1gyOj8c1a5fxGXV4%2FOEOM%3D&amp;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
>
>


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

Steve Brown
 

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://github.com/zephyrproject-rtos/zephyr/pull/29739

Please test it and provide feedback if you can.

Thanks for the detailed bug report!

Trond

From: Steve Brown <sbrown@ewol.com>
Sent: Monday, November 2, 2020 18:13
To: zephyr-devel@lists.zephyrproject.org <
zephyr-devel@lists.zephyrproject.org>
Cc: Snekvik, Trond <Trond.Einar.Snekvik@nordicsemi.no>
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


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

Steve Brown
 

Hi Trond,

The patch didn't fix the problem. I've attached the meshd and zephyr
debug output.

Steve

MESHD
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/node.c:dev_key_send_call() DevKeySend
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/model.c:mesh_model_send() mesh_model_send entered msg_len 0003
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/model.c:msg_send() msg_send entered: msg_len: 0003
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/model.c:mesh_model_rx() iv_index 00000000 key_aid = 00
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:send_seg() segN 0 segment 0 seg_off 0
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93738.961 Clr-Net Tx: 007f00000d000100aa00dd6f95b73a165c00000000
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93738.962 RX: Network [enc] :: 08ee4529cf4f9b4ad5f11b7e12d6e2b5f7aaaaab2c
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93738.962 RX: Network [clr] :: 087f00000d000100aa00dd6f95b73a165c
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93738.973 RX: Network [enc] :: 0870773c224755ec3a59147e44df996c33f1314f7ad4bb74a76f148166
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93738.973 RX: Network [clr] :: 080700001000aa0001808040048d32264e904a86e51d1faca4
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:msg_in_cache() Add 00aa + 000010 + 904a86e5
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: RX: Network 00aa -> 0001 : TTL 0x07 : IV : 00000000 SEQ 0x000010 : RSSI -64
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: RX: App 0x00aa -> 0x0001 : TTL 0x07 : SEQ 0x000010 : RSSI -64
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() RXed (new: 0010 000010 size: 12 len: 60) 0 of 4
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() Queue Size: 0
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() First Seg 0000
Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() NAK: 1 expected:0000001f largest:0000001f flags:00000001
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.094 RX: Network [enc] :: 08464c2b449dfb949f95719d40db06f716b3d59153c0065fe0e7c38c24
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.094 RX: Network [clr] :: 080700001100aa000180804024db714c0a58f47c3969824188
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:msg_in_cache() Add 00aa + 000011 + 58f47c39
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: Network 00aa -> 0001 : TTL 0x07 : IV : 00000000 SEQ 0x000011 : RSSI -63
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: App 0x00aa -> 0x0001 : TTL 0x07 : SEQ 0x000011 : RSSI -63
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() RXed (old: 0010 000011 size:12) 1 of 4
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() NAK: 1 expected:0000001f largest:0000001e flags:00000003
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.216 RX: Network [enc] :: 0863652c2d41a065270a3080632b7e6dd8578d3007f9f4886bedac4d60
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.216 RX: Network [clr] :: 080700001200aa000180804044ae8709c296e7ef543a2dc728
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:msg_in_cache() Add 00aa + 000012 + 96e7ef54
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: Network 00aa -> 0001 : TTL 0x07 : IV : 00000000 SEQ 0x000012 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: App 0x00aa -> 0x0001 : TTL 0x07 : SEQ 0x000012 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() RXed (old: 0010 000012 size:12) 2 of 4
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() NAK: 1 expected:0000001f largest:0000001c flags:00000007
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.337 RX: Network [enc] :: 08dccaf88a308e5c13fed895ba3ff56430b7beb8016329cc2e39f02853
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.337 RX: Network [clr] :: 080700001300aa000180804064f8f2e2ca3c5dfd10f57a2e5e
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:msg_in_cache() Add 00aa + 000013 + 3c5dfd10
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: Network 00aa -> 0001 : TTL 0x07 : IV : 00000000 SEQ 0x000013 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: App 0x00aa -> 0x0001 : TTL 0x07 : SEQ 0x000013 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() RXed (old: 0010 000013 size:12) 3 of 4
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() NAK: 1 expected:0000001f largest:00000018 flags:0000000f
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.486 RX: Network [enc] :: 08a4cc8cb59cb690e547277c1e15aff2263b0f62a7ae9c
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.486 RX: Network [clr] :: 080700001400aa000180804084b53f74e0973a
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:msg_in_cache() Add 00aa + 000014 + 4084b53f
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: Network 00aa -> 0001 : TTL 0x07 : IV : 00000000 SEQ 0x000014 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: RX: App 0x00aa -> 0x0001 : TTL 0x07 : SEQ 0x000014 : RSSI -64
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:seg_rxed() RXed (old: 0010 000014 size:6) 4 of 4
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/net.c:send_net_ack() Send ACK to Segs: 0000001f
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/model.c:mesh_model_rx() iv_index 00000000 key_aid = 00
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: model.c - Failed to decrypt application payload
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.488 RX: Network [enc] :: 08b0b85593f65359b8700da848ae7429129b05bbbb3f48fe
Nov 3 03:55:39 mesh0 bluetooth-meshd[21346]: mesh/util.c:print_packet() 93739.488 RX: Network [clr] :: 08ff000010000100aa0000400000001f

zephyr
[14:52:52.859,710] <dbg> bt_mesh_cfg_srv.dev_comp_data_get: net_idx 0x0000 app_idx 0xfffe src 0x0001 len 1: 00
[14:52:52.859,741] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[14:52:52.859,771] <dbg> bt_mesh_access.model_send: len 50: 0200f105000000000a0003000000050~
[14:52:52.859,771] <dbg> bt_mesh_transport.bt_mesh_trans_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[14:52:52.859,802] <dbg> bt_mesh_transport.bt_mesh_trans_send: len 50: 0200f105000000000a0003000000050~
[14:52:52.859,954] <dbg> bt_mesh_transport.send_seg: src 0x00aa dst 0x0001 app_idx 0xfffe aszmic 1 sdu_len 54
[14:52:52.859,985] <dbg> bt_mesh_transport.send_seg: SeqZero 0x000b (segs: 5)
[14:52:52.859,985] <dbg> bt_mesh_transport.send_seg: seg 0: 86044bbdb2d803234191a592
[14:52:52.860,015] <dbg> bt_mesh_transport.send_seg: seg 1: 1271612ba4accf550958b3df
[14:52:52.860,015] <dbg> bt_mesh_transport.send_seg: seg 2: 43943905c3f425318a493eec
[14:52:52.860,046] <dbg> bt_mesh_transport.send_seg: seg 3: ad581efacf03a6d519833d03
[14:52:52.860,076] <dbg> bt_mesh_transport.send_seg: seg 4: 9f6585f87caa
[14:52:52.860,076] <dbg> bt_mesh_transport.seg_tx_send_unacked: SeqZero: 0x000b Attempts: 4
[14:52:52.860,107] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 0/4
[14:52:52.860,107] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x00aa dst 0x0001 len 16 headroom 9 tailroom 4
[14:52:52.860,107] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80802c0486044bbdb2d803234191a59~
[14:52:52.860,137] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x00000b
[14:52:52.860,137] <dbg> bt_mesh_net.net_header_encode: src 0x00aa dst 0x0001 ctl 0 seq 0x00000b
[14:52:52.860,290] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 1/4
[14:52:52.860,321] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x00aa dst 0x0001 len 16 headroom 9 tailroom 4
[14:52:52.860,321] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80802c241271612ba4accf550958b3d~
[14:52:52.860,321] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x00000c
[14:52:52.860,351] <dbg> bt_mesh_net.net_header_encode: src 0x00aa dst 0x0001 ctl 0 seq 0x00000c
[14:52:52.860,565] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 2/4
[14:52:52.860,595] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x00aa dst 0x0001 len 16 headroom 9 tailroom 4
[14:52:52.860,595] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80802c4443943905c3f425318a493ee~
[14:52:52.860,595] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x00000d
[14:52:52.860,626] <dbg> bt_mesh_net.net_header_encode: src 0x00aa dst 0x0001 ctl 0 seq 0x00000d
[14:52:52.860,778] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 3/4
[14:52:52.860,778] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x00aa dst 0x0001 len 16 headroom 9 tailroom 4
[14:52:52.860,809] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 16: 80802c64ad581efacf03a6d519833d0~
[14:52:52.860,809] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x00000e
[14:52:52.860,809] <dbg> bt_mesh_net.net_header_encode: src 0x00aa dst 0x0001 ctl 0 seq 0x00000e
[14:52:52.860,961] <dbg> bt_mesh_transport.seg_tx_send_unacked: Sending 4/4
[14:52:52.860,992] <dbg> bt_mesh_net.bt_mesh_net_send: src 0x00aa dst 0x0001 len 10 headroom 9 tailroom 10
[14:52:52.860,992] <dbg> bt_mesh_net.bt_mesh_net_send: Payload len 10: <log_strdup alloc failed>
[14:52:52.860,992] <dbg> bt_mesh_net.bt_mesh_net_send: Seq 0x00000f
[14:52:52.861,022] <dbg> bt_mesh_net.net_header_encode: src 0x00aa dst 0x0001 ctl 0 seq 0x00000f
[14:52:52.861,114] <dbg> bt_mesh_access.bt_mesh_model_recv: No OpCode 0x00008008 for elem 1
[14:52:52.861,145] <dbg> bt_mesh_access.bt_mesh_model_recv: No OpCode 0x00008008 for elem 2
[14:52:52.861,145] <dbg> bt_mesh_access.bt_mesh_model_recv: No OpCode 0x00008008 for elem 3
[14:52:53.358,947] <dbg> bt_mesh_net.bt_mesh_net_recv: rssi -51 net_if 0

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://github.com/zephyrproject-rtos/zephyr/pull/29739

Please test it and provide feedback if you can.

Thanks for the detailed bug report!

Trond

From: Steve Brown <sbrown@ewol.com>
Sent: Monday, November 2, 2020 18:13
To: zephyr-devel@lists.zephyrproject.org <
zephyr-devel@lists.zephyrproject.org>
Cc: Snekvik, Trond <Trond.Einar.Snekvik@nordicsemi.no>
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


SUCCESS


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

Trond Snekvik
 

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).


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



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

Steve Brown
 

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


API meeting: agenda

Carles Cufi
 

Hi all,

Agenda for tomorrow.

Note: the API and component naming conventions (https://github.com/zephyrproject-rtos/zephyr/issues/29569) discussion has been postponed until next week since tomorrow the availability of US-based engineers is restricted.

- devicetree-based device definitions and dependency representations
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/29644

- Reminder and questions about: API to correlate system time with external time sources and translate uptime to wall-clock time
- PR https://github.com/zephyrproject-rtos/zephyr/pull/28977

- Introduction of a new work queue
- PR https://github.com/zephyrproject-rtos/zephyr/pull/29618

and then, time permitting we'd like to follow-up on pinctrl:

- 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: Zephyr Toolchain Working Group Meeting – 2 November 2020

Rasmussen, Torsten
 

Today’s MoM:

 

Notes/Minutes

  • LLVM
    • #24917, infrastructure in place and works, when linking with GNU ld.
      • Work needed regarding:
        • Linking with llvm-ld (log2ceil)
        • Linking with llvm-ldd
        • Compiler-rt
  • Zephyr SDK
    • Beta Zephyr SDK 0.12 last week
    • Outstanding issue on Zephyr side, arm64, #28650
    • ARC / TLS support ?
      • On ARC the build itself doesn’t seem to enable it.
    • Eugeniy will look into this.
    • Cleanup and add Kconfig regarding TLS support, default to `n`
      Also allow users to specify if he know the toolchain support TLS
      • Newlib should be part of this cleanup   
      • Are we mixing Kconfig too much with toolchain properties ?
      • Having information in both places, having CMake drives the Kconfig values ?
    • Nothing happening on new packaging regarding Windows / macOS platform
      • No further work is expected to happen regarding Zephyr SDK for Windows / MacOS, unless someone has the time and volunteers to drive this forward.
        It’s better to focus resources on better toolchain support, such as LLVM.

 

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

 

Thanks to all participants for good discussions.

 

/torsten

 

From: Rasmussen, Torsten
Sent: 2 November, 2020 14:37
To: devel@...
Subject: Zephyr Toolchain Working Group Meeting – 2 November 2020

 

Call for today’s Toolchain WG.

 

Agenda

 

·         Updates:

o    Thomas: IAR: Updates ?

o    Zephyr SDK.

§  LLVM support

§  compiler-rt.

o    #24917

§  Linking with lld.

§  Compiler-rt ?

o    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

 

           

 


Network forum agenda

Jukka Rissanen
 


Re: #LWM2M #Leshan #FirmwareUpdate #lwm2m #leshan #firmwareupdate

Lubos, Robert
 

Hi Thomas,

 

I’m not sure if the firmware update is even achievable on qemu_x86 platform (same goes with reboot). The lwm2m_client sample does not implement the actual FW update procedure, just provide stubs to get the communication going.

 

I’ve included some more replies inline below.

 

Regards,

Robert

 

From: devel@... <devel@...> On Behalf Of Thomas LE ROUX via lists.zephyrproject.org
Sent: poniedziałek, 2 listopada 2020 17:14
To: devel@...
Subject: [Zephyr-devel] #LWM2M #Leshan #FirmwareUpdate

 

Hi everybody !

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

TL;DR before I start explaining more precisely my issue :

Having issue making a Firmware Update on a QEMU_x86 instance.

Has anyone been able to successfully achieve a Firmware Upgrade ? How ?

 

For now, I'm prototyping through QEMU.

I have made my small application to test things out, creating objects and ressources ; defining new .xml files … There's one last thing that I need to succeed before going deeper into my project : Firmware Update. I am unable to make a firmware update on my QEMU instance.

I am actually using a Leshan localhost as my LWM2M server.

I’ve tried several things :

  • Pushing using 5/0/0 :
    • File above 200ko can’t be pushed without an issue occuring (packets stop downloading and 5/0/3 remain at the value 1 (meaning « downloading ») afterwards.

Try increasing the “Response Timeout” parameter in the Leshan web UI. The Leshan will cease to transmit further updates if it does not finish the operation before “Response timeout”.

    • The .elf generated for samples/basic/hello_world is around 400ko which causes an issue here.
    • The .bin generated, however, weight around 100ko which is fine.
      • The file uploads (result can be seen on my terminal).
        • [00:00:28.040,000] <inf> net_lwm2m_client_app: FIRMWARE: BLOCK RECEIVED: len:37 last_block:1
      • The 5/0/3 State value goes to 2 (« downloaded »).
      • When I execute 5/0/2 (Update) : 5/0/5 (Update Result) goes to 1 (meaning Firmware updated successfully).
      • However, nothing happens, and my QEMU continue to respond to requests, no flash occurs.

Nothing else can be expected from the sample at this point (as I said I’m not sure if it’s possible to do the actual firmware update of the qemu_x86 image). From the LwM2M point of view, the FW update procedure is complete as the entire image was delivered to the device. You can check how does it work with an actual device for instance here:
https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/lwm2m_client/src/lwm2m/lwm2m_firmware.c

  • Pulling using 5/0/1 :
    • I've run a local server in order to make a firmware update through 5/0/1 by giving the http address of .bin and .elf.
    • When I try to Update (for .elf or .bin, i have the following Update Result : 9 (meaning « Unsupported protocol » )

This is happening because http is not implemented as a FW delivery method in the LwM2M library. For now, only CoAP block transfer is supported.

The problem might be related to the fact that some functions are not yet implemented in Zephyr (e.g : Device reboot on 3/0/4 leads to a callback doing « /* Change the battery voltage for testing */ » and no reboot, same for Factory Default ) …

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

 

Thank you for your help !

Best regards,

Thomas

 


#LWM2M #Leshan #FirmwareUpdate #lwm2m #leshan #firmwareupdate

Thomas LE ROUX
 

Hi everybody !

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

TL;DR before I start explaining more precisely my issue :

Having issue making a Firmware Update on a QEMU_x86 instance.

Has anyone been able to successfully achieve a Firmware Upgrade ? How ?


For now, I'm prototyping through QEMU.

I have made my small application to test things out, creating objects and ressources ; defining new .xml files … There's one last thing that I need to succeed before going deeper into my project : Firmware Update. I am unable to make a firmware update on my QEMU instance.

I am actually using a Leshan localhost as my LWM2M server.

I’ve tried several things :

  • Pushing using 5/0/0 :

    • File above 200ko can’t be pushed without an issue occuring (packets stop downloading and 5/0/3 remain at the value 1 (meaning « downloading ») afterwards.

    • The .elf generated for samples/basic/hello_world is around 400ko which causes an issue here.

    • The .bin generated, however, weight around 100ko which is fine.

      • The file uploads (result can be seen on my terminal).

        • [00:00:28.040,000] <inf> net_lwm2m_client_app: FIRMWARE: BLOCK RECEIVED: len:37 last_block:1

      • The 5/0/3 State value goes to 2 (« downloaded »).

      • When I execute 5/0/2 (Update) : 5/0/5 (Update Result) goes to 1 (meaning Firmware updated successfully).

      • However, nothing happens, and my QEMU continue to respond to requests, no flash occurs.

  • Pulling using 5/0/1 :

    • I've run a local server in order to make a firmware update through 5/0/1 by giving the http address of .bin and .elf.

    • When I try to Update (for .elf or .bin, i have the following Update Result : 9 (meaning « Unsupported protocol » )

The problem might be related to the fact that some functions are not yet implemented in Zephyr (e.g : Device reboot on 3/0/4 leads to a callback doing « /* Change the battery voltage for testing */ » and no reboot, same for Factory Default ) …

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


Thank you for your help !

Best regards,

Thomas



Zephyr: Toolchain Working Group - Mon, 11/02/2020 #cal-notice

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

Zephyr: Toolchain Working Group

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

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr: Toolchain Working Group - Mon, 11/02/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Maureen Helm

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr Toolchain Working Group Meeting – 2 November 2020

Rasmussen, Torsten
 

Call for today’s Toolchain WG.

 

Agenda

 

  • Updates:
    • Thomas: IAR: Updates ?
    • Zephyr SDK.
      • LLVM support
        • compiler-rt.
    • #24917
      • Linking with lld.
      • Compiler-rt ?
    • 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

 

           

 


#uart #uart

yuta.uenishi@...
 

Hello,

I am using the stm32l152re,
I am using the mdm_receiver driver to use uart in my project.
I want to use a pointer to a callback function in my project to do a k_work_submit in a UART callback.
Is there a driver that meets my requirements?

Thanks,

Yuta


Re: Updated Event: Zephyr: Networking Forum #cal-invite

Jukka Rissanen
 

Hi all,

Tuesday (3 Nov) there is a networking forum Teams meeting. Let me know
if there are any network related topic you would like to discuss there
so I can add it to the agenda.


Cheers,
Jukka


Updated Event: Zephyr Project: Dev Meeting #cal-invite

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

Zephyr Project: Dev Meeting

When:
Thursday, 5 November 2020
4:00pm to 5:00pm
(UTC+00:00) UTC
Repeats: Weekly on Thursday

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

501 - 520 of 7931