ATT_FIND_INFO_REQ fails for 128-bit UUID services and characteristics

[ThomasGerstenberg]

When performing a FIND_INFO_REQ over handles which include a 128-bit service UUID, the response is a malformed packet, specifying type 2 (128-bit UUID) but only copying 16-bits

The ternary on this line here needs to be inverted from

ArduinoBLE/src/utility/ATT.cpp

Line 686 in 840501e

int uuidLen = isValueHandle ? 2 : attribute->uuidLength();

To

int uuidLen = isValueHandle ? attribute->uuidLength() : 2;

This makes sense because the only 128-bit UUIDs that should be returned are value handles, otherwise they'll be 16-bit.

Snippet of malformed packet:

[polldo]

Hi @ThomasGerstenberg , thanks for reporting.
I'm not sure the fix you suggested will actually fix the issue, have you tried it?
I'm telling you this because here the problem is that in ArduinoBLE library the services discovery is performed by using ATT_READ_BY_GROUP_TYPE requests and responses, while the FIND_INFO_REQ is used for the discovery of characteristics' descriptors as detailed in BLE core specification (vol. 3, part G, chapter 4.4 and 4.7).

So, when a find information request is received, the ATTClass::findInfoReq function will look for descriptors. If the handles contained in the range specified in the request does not belong to descriptors, then the type of the attribute found is returned instead of its uuid. (Indeed, the value 0x2800 that you are receiving, is the uuid corresponding to Primary Services type)

ArduinoBLE/src/utility/ATT.cpp

Lines 706 to 712 in 840501e

	} else {
	// add the type
	uint16_t type = attribute->type();
	memcpy(&response[responseLength], &type, sizeof(type));
	responseLength += sizeof(type);
	}

In conclusion, yes, there is a bug because when an attribute that is not a descriptor is found, its type should be returned with format 0x01 (because all attributes types uuid are composed by 16 bits). However, if you are using FIND_INFO_REQ for service discovery you could have problems.

[ThomasGerstenberg]

Tested the fix and it works, can provide wireshark captures later.

FIND_INFO_REQ was used for descriptor discovery, service discovery as you mentioned used ATT_READ_BY_GROUP_TYPE. Your assessment is correct that in this case the expected format should be 16-bit 0x01 with value 0x2800 since it's a service declaration attribute, so the issue is that the format reported is incorrect.

The descriptor discovery implementation I used was "naive" in that it scanned all handles for descriptors without taking into account handles already discovered from service/characteristic discovery. So for example it started FIND_INFO_REQ over handles 1 to 0xFFFF. It returned attributes with format 0x01, then stopped at the 128-bit service handle since it thought the format for that handle should be 0x02. Descriptor discovery picked back up at that handle which returned the malformed packet seen above.
Side note: I've since changed my implementation to be smarter in this regards which side-steps the issue since I no longer start descriptor discovery on a service handle or characteristic declaration/value handles

[polldo]

@ThomasGerstenberg could you test this PR? #148
Thanks for helping

[polldo]

@ThomasGerstenberg Thanks a lot for your help!
Anyway your blatann project is really cool 👍

Closing as solved #148