Fix find info resp when called on non-descriptor attributes#148
Merged
polldo merged 1 commit intoarduino-libraries:masterfrom Dec 14, 2020
Merged
Fix find info resp when called on non-descriptor attributes#148polldo merged 1 commit intoarduino-libraries:masterfrom
polldo merged 1 commit intoarduino-libraries:masterfrom
Conversation
src/utility/ATT.cpp
Outdated
| bool isValueHandle = (attribute->type() == BLETypeCharacteristic) && (((BLELocalCharacteristic*)attribute)->valueHandle() == handle); | ||
| int uuidLen = isValueHandle ? 2 : attribute->uuidLength(); | ||
| bool isDescriptor = attribute->type() == BLETypeDescriptor; | ||
| int uuidLen = isValueHandle ? 2 : (isDescriptor ? attribute->uuidLength() : BLE_ATTRIBUTE_TYPE_SIZE); |
There was a problem hiding this comment.
I don't think this is correct. If it's a value handle, it should use the attribute's UUID length right?
If we align it with the if logic on 703, value and descriptor handles memcpy the UUID data, so the uuidLen should reflect as such. Otherwise use the type size of 2
int uuidLen = (isValueHandle || isDescriptor) ? attribute->uuidLength() : BLE_ATTRIBUTE_TYPE_SIZE;
// also can update the if on 703 to match
if (isValueHandle || isDescriptor) {
// add the UUID
} else {
// add the type
}
Contributor
Author
There was a problem hiding this comment.
Yes you're definitely right!
I'm going to update the PR
Before this fix, if the 'ATT information request' was called on an handle belonging to a non-descriptor attribute, then the response would contain the uuid of the actual attribute's type but with the format of the attribute uuid (0x01 for 16 bit length, 0x02 for 128 bit length). So, for instance, if the info request was performed on an handle belonging to a service with a uuid of 128 bit, then the response would have been malformed because the size of the attribute's type is 16 bit.
polldo
force-pushed
the
fix-find-info-resp
branch
from
4589b0e to
de759d4
Compare
ThomasGerstenberg
approved these changes
Dec 12, 2020
ThomasGerstenberg
left a comment
ThomasGerstenberg
left a comment
There was a problem hiding this comment.
Tested fix and it works 👍
Capture of handle 0x0e being discovered as a 16-bit uuid
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before this fix, if the
ATT information requestwas called on an handle belonging to a non-descriptor attribute, then the response would contain the uuid of the actual attribute's type but with the format of the attribute uuid (0x01 for 16 bit length, 0x02 for 128 bit length).So, for instance, if the info request was performed on an handle belonging to a service with a uuid of 128 bit, then the response would have been malformed because the size of the attribute's type is 16 bit.
From issue discovered by @ThomasGerstenberg
#147