-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Bluetooth: Host: Inconsistent permission value during discovery procedure #29083
Comments
@boachair What is the annoyance there? The permissions on the field is not sent, which is why it is not set of the attribute structure. I don't see setting it to "READ" as something that provides any useful information. |
There exists a difference in discovering service and characteristics, i.e., Characteristic discovery returns the permission field as 1 (READ only) in the callback, while Primary Service/included service discovery return this permission as 0. However, the requirement for attribute permission are the same for both. |
@boachair Yes I noticed that, and I'd like to fix that. However what I would like to do is to set it to 0 in all cases, and then document that this field is not valid in the discovery callback. Setting them to be "READ" would only be misleading, since we don't actually know the correct permissions, and there is no way to retrieve them either. |
Be consistent in the permission handling of the discovered attribute in the temporary object given in the discovery callback. For characteristics the permission field was set to READ, while for all other attributes it was set to 0. Fixes: zephyrproject-rtos#29083 Signed-off-by: Joakim Andersson <[email protected]>
@nashif I set it to low instead. It's just an inconsistency in the parameters, nothing is missing. |
Be consistent in the permission handling of the discovered attribute in the temporary object given in the discovery callback. For characteristics the permission field was set to READ, while for all other attributes it was set to 0. Fixes: #29083 Signed-off-by: Joakim Andersson <[email protected]>
Describe the bug
After calling Zephyr Bluetooth API, bt_gatt_discover(), GATT client expects a response structured as Attribute, which contains one permission field (see below). However, it is always 0 now. It might be caused because the GATT server response does not update this attribute permission.
--
struct bt_gatt_attr {
/** Attribute UUID /
const struct bt_uuid uuid;
...
/ Attribute user data /
void user_data;
/ Attribute handle /
u16_t handle;
/* Attribute permissions */
u8_t perm;
};
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The Attribute Permissions shall be read-only (BT_GATT_PERM_READ).
Impact
annoyance
Logs and console output
None
Environment (please complete the following information):
Additional context
None
The text was updated successfully, but these errors were encountered: