QUERY · ISSUE

AIOBLE - ScanResult only returns first service when multiple are present in advertisement

openby raleopened 2021-12-31updated 2024-05-11

When a device advertises multiple service UUIDs, it seems only the first one gets decoded.

I'm doing something like:

async with aioble.scan(5000, interval_us=30000, window_us=30000, active=True) as scanner:
    async for result in scanner:
        for service in result.services():
            print(service)

With an advertising packet like this:
020106050318182618
I think result.services() should yield both 0x1818 and 0x1826, but it only seems to decode the first one.

2 comments

jimmo · 2022-08-05

With an advertising packet like this:
020106050318182618
I think result.services() should yield both 0x1818 and 0x1826, but it only seems to decode the first one.

Thanks, this is a bug, we do not current handle the decoding case where multiple service UUIDs are encoded into the same field (as an optimisation we should also handle this on the encode side too).

aetelani · 2024-05-11

I don't get service data work wither, for example sending temperature values to central. Manufacturer information seems to work though.

CANDIDATE · PULL REQUEST

micropython/aioble: Place multiple UUIDs in single advertisement LTV.

mergedby xyzzy42opened 2024-01-10updated 2024-05-25

When multiple UUIDs of the same size are advertised, they should all be listed in a single LTV. Supplement to the Bluetooth Core Specification, Part A, §1.1.1: "A packet or data block shall not contain more than one instance for each Service UUID data size."

When aioble construct the advertisement data, it is creating a new data block for each UUID that contains only that single UUID. Rather than, e.g., a single 16-bit UUID block with a list of multiple UUIDs.

Not only is this against the specification, it wastes two bytes of limited advertisement space per UUID beyond the first for the repeated data block length and type fields.

Fix this by grouping each UUID size together.

4 comments

dpgeorge · 2024-05-24

Thanks for the contribution. What you've done here looks correct, according to the BT Core Supplement.

A few points:

Prior to this change, if the user specifies a list of services then the order in which they specify them is the order they appear in the advertising data. With this change, 16-bit services appear first, then 32-bit, then 128-bit. That probably doesn't matter but worth discussing.
The aioble central logic will need to change to be compatible with the fix in this PR. The central code currently assumes that a service field contains exactly one service, and that will have to be extended to support 0 or more services per field (the spec apparently allows a zero length payload in the service field, to indicate no services of this size are available on this peripheral).

xyzzy42 · 2024-05-24

I chose the order of increasing size so as to pack the most services possible into the available space. I thought that would be the best result, if there are more services advertised than fit in the available space. If someone is concerned about exactly what services are advertised, then they should probably not try to advertise more than can fit in the packet, in which case the order should not matter.

As I understand it, the aioble central logic is decoding the advertisement data from any other BLE device. The fact that it can't decode BT spec compliant data is a bug that should be triggered already by existing devices, regardless of whether aioble peripherals generate spec compliant advertising data or not.

dpgeorge · 2024-05-24

I chose the order of increasing size so as to pack the most services possible into the available space. I thought that would be the best result, if there are more services advertised than fit in the available space.

Yes, that makes sense.

If someone is concerned about exactly what services are advertised, then they should probably not try to advertise more than can fit in the packet, in which case the order should not matter.

If needed the user can specify the exact byte format of the advertising/response data, so they do have full control over it if needed.

As I understand it, the aioble central logic is decoding the advertisement data from any other BLE device. The fact that it can't decode BT spec compliant data is a bug that should be triggered already by existing devices,

Yes you are correct, fixing the central can be done separately.

dpgeorge · 2024-05-25

See #863 for the corresponding fix on the central side.

AIOBLE - ScanResult only returns first service when multiple are present in advertisement

micropython/aioble: Place multiple UUIDs in single advertisement LTV.

Keyboard