spp: fix SDP proto list handling for RFCOMM channel#455
spp: fix SDP proto list handling for RFCOMM channel#455huangyulong3 merged 2 commits intoopen-vela:devfrom
Conversation
chengkai15
requested review from
gzh-terry,
huangyulong3,
hyson710,
zhangyuan376 and
zhongzhijie1
as code owners
chengkai15
force-pushed
the
bug_spp_sdp
branch
from
03e3b9a to
a8d7382
Compare
| spp_record->attrs[i].val.data = spp_record->svclass_id_list; | ||
| } else if (spp_record->attrs[i].id == BT_SDP_ATTR_PROTO_DESC_LIST) { | ||
| struct bt_sdp_data_elem* element = (struct bt_sdp_data_elem*)&spp_record->attrs[i].val; | ||
| struct bt_sdp_data_elem* list_tmpl = (struct bt_sdp_data_elem*)spp_record->attrs[i].val.data; |
There was a problem hiding this comment.
abbreviation of template
There was a problem hiding this comment.
Pull request overview
Fixes Zephyr SPP SDP record construction to avoid mutating shared SDP PROTO_DESC data in-place, preventing RFCOMM channel element pointer corruption and incorrect SDP records.
Changes:
- Extends
spp_sdp_record_tto hold per-record copies of SDP data element arrays (service class list and protocol descriptor lists). - Updates
spp_sdp_create_record()to repoint SDP attributeval.datato these per-record copies and safely patch the RFCOMM channel element.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| memcpy(spp_record->attrs, spp_attrs_template, sizeof(spp_attrs_template)); | ||
|
|
||
| sys_memcpy_swap(spp_record->uuid128, uuid->val.u128, BT_UUID_SIZE_128); | ||
| memcpy(spp_record->uuid128, uuid->val.u128, BT_UUID_SIZE_128); |
There was a problem hiding this comment.
UUID128 byte order handling changed from sys_memcpy_swap() to memcpy(). Elsewhere in this file Classic SDP discovery still swaps UUID bytes before passing to Zephyr (sys_memcpy_swap at ~801), so this likely reintroduces an endianness mismatch in the advertised Service Class ID (remote peers may see a different UUID than intended). Keep the byte swap here (or otherwise ensure the SDP record uses the byte order expected by Zephyr SDP).
| memcpy(spp_record->uuid128, uuid->val.u128, BT_UUID_SIZE_128); | |
| sys_memcpy_swap(spp_record->uuid128, uuid->val.u128, BT_UUID_SIZE_128); |
There was a problem hiding this comment.
which was handle it stack open-vela/external_zblue#167
| spp_record->proto_desc_rfcomm[1] = rfcomm_tmpl[1]; | ||
| spp_record->proto_desc_rfcomm[1].data = &spp_record->channel; | ||
|
|
||
| spp_record->proto_desc_list[1].data = spp_record->proto_desc_rfcomm; |
There was a problem hiding this comment.
The RFCOMM channel SDP element is declared as BT_SDP_UINT8 in the template, but the code points it at spp_record->channel which is a uint16_t. On little-endian targets this often “works by accident” (low byte first), but it can produce an incorrect channel value on big-endian targets and is type-inconsistent with the SDP element size. Store the channel in a uint8_t field (or a dedicated uint8_t temp) and point the SDP element to that.
There was a problem hiding this comment.
which was handled in stack
bug: v/85645 rootcause:The SDP PROTO_DESC list was modified in place without copying, so the RFCOMM channel element pointer could become invalid or corrupt, leading to incorrect SDP records. Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
bug: v/85645 rootcause: SPP SDP records used the wrong UUID byte order and reused template data, so later registrations overwrote previous RFCOMM channel/UUID and triggered false duplicates. Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
chengkai15
force-pushed
the
bug_spp_sdp
branch
from
a8d7382 to
1dc1424
Compare
4 participants
bug: v/85645
rootcause:The SDP PROTO_DESC list was modified in place without copying, so the RFCOMM channel element pointer could become invalid or corrupt, leading to incorrect SDP records.