wireless/bluetooth: Fix record stride in descriptor discovery response.

[acassis]

Summary

att_find_info_rsp() computed the per-record stride with sizeof(info.i16) and sizeof(info.i128), but "info" is a union of two pointers, so both expressions evaluate to the pointer width instead of the size of the record that the response format selects. The records are 4 octets for a 16-bit UUID and 18 octets for a 128-bit UUID, so the 128-bit path advanced by 4 (or 8) octets per iteration while reading an 18-octet record: handles and UUIDs were parsed from the wrong offsets and the walk ran past the end of the received PDU. On 64-bit builds the 16-bit path was wrong too.

Take the stride from the record structures, and require the response to carry whole records before walking it, since the loop advances one record at a time and a partial trailing record would be parsed as a whole one.

Improvement

Testing

before this patch:

att_find_info_rsp: handle 0x0010
btnet_discover_func: Discovered handle 10
att_find_info_rsp: handle 0x0706
btnet_discover_func: Discovered handle 706
Discovered 2 handles:

after this patch:

att_find_info_rsp: handle 0x0010
btnet_discover_func: Discovered handle 10
Discovered 1 handles:

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb