Re: #ble #ble

Chettimada, Vinayak Kariappa

Hi Carl,

Thank you for reporting the issue. You may send a pull request to fix accordingly and I will be glad to review the same.

As this is a bug, we could get this in for the 2.6 release.


From: devel@... <devel@...> on behalf of Carl Stehle via <>
Sent: Thursday, May 27, 2021 7:28:17 AM
To: devel@... <devel@...>
Subject: [Zephyr-devel] #ble

I was unable to consistently set BLE Periodic Advertising Data, so had a look at:

subsys/bluetooth/controller/ll_sw/ull_adv_sync.c: adv_sync_hdr_set_clear()
(this is with recent commit f5c6afeccb53e4121ba5e97294cf589a752623d9)

I noticed 2 potential issues:

1. ter_hdr_prev = *ter_hdr;

If the Extended Header Length is 0, this can copy data (first byte of Adv Data) with misleading results. One workaround would be to replace that line with:

if (ter_com_hdr_prev->ext_hdr_len) {
  ter_hdr_prev = *ter_hdr;
} else {
  memset(&ter_hdr_prev, 0, sizeof(ter_hdr_prev));

2. ter_len = ull_adv_aux_hdr_len_calc(ter_com_hdr, &ter_dptr);

This can reset ter_dptr if the Extended Header Length is 0 so that it has the same value as ter_hdr. So ter_hdr should not be used after this call without first checking for non-zero Extended Header length (either ter_com_hdr->ext_hdr_len non-zero or that ter_hdr differs from ter_dptr).


Join to automatically receive all group messages.