Skip to content

bt_gatt_attr_read_chrc: no characteristic for value #12159

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
HesselM opened this issue Dec 18, 2018 · 0 comments
Closed

bt_gatt_attr_read_chrc: no characteristic for value #12159

HesselM opened this issue Dec 18, 2018 · 0 comments
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug

Comments

@HesselM
Copy link
Contributor

HesselM commented Dec 18, 2018

When performing a bt_gatt_discover with BT_GATT_DISCOVER_CHARACTERISTIC, the read-callback in the user_data, sometimes shows the message:
bt_gatt.bt_gatt_attr_read_chrc: No value for characteristic at 0x<XXXX>

In bt_gatt_attr_read_chrc, the following tries to read the value-handle:

	/* BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 534:
	 * 3.3.2 Characteristic Value Declaration
	 * The Characteristic Value declaration contains the value of the
	 * characteristic. It is the first Attribute after the characteristic
	 * declaration. All characteristic definitions shall have a
	 * Characteristic Value declaration.
	 */
	next = bt_gatt_attr_next(attr);
	if (!next) {
		BT_WARN("No value for characteristic at 0x%04x", attr->handle);
		pdu.value_handle = 0x0000;
	} else {
		pdu.value_handle = sys_cpu_to_le16(next->handle);
	}

bt_gatt_attr_next(..) does some swapping(?) of the user_data and the attribute-parameters, which are two completely different structures: for a characteristic-discovery, the user_data of the attribute is a struct bt_gatt_chrc, whereas the attribute itself is a struct bt_gatt_attr.

With the value-declaration being the first attribute after the characteristic definition, I think that the value-handle can be computed alternatively as:

pdu.value_handle = sys_cpu_to_le16(attr->handle + 1);

I'm using the Zephyr source of commit 32ce219 and a PCA10056 dev-board.

@HesselM HesselM added the bug The issue is a bug, or the PR is fixing a bug label Dec 18, 2018
Vudentz added a commit to Vudentz/zephyr that referenced this issue Jan 2, 2019
When using bt_gatt_discover with BT_GATT_DISCOVER_CHARACTERISTIC the
read callback would be set to bt_gatt_attr_read_chrc which would attempt
to access the next attribute which in this case would not be set since
the value attribute is no fetched by the discovery, the spec actually
omit the value handle saying it should always be the first attribute to
appear after the characteristic thus we can assume it to be handle + 1.

Fixes zephyrproject-rtos#12159

Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

No branches or pull requests

2 participants