Skip to content
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

Closed
laxiLang opened this issue Oct 9, 2020 · 4 comments · Fixed by #29163
Closed

Bluetooth: Host: Inconsistent permission value during discovery procedure #29083

laxiLang opened this issue Oct 9, 2020 · 4 comments · Fixed by #29163
Assignees
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@laxiLang
Copy link
Contributor

laxiLang commented Oct 9, 2020

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:

  1. call Zephyr API, bt_gatt_discover() with discover type as the primary service
  2. Read the permission field in the response (structured as Attribute) in the callback

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):

  • Zephyr 2.4.0
  • nRF52840 DK

Additional context
None

@laxiLang laxiLang added the bug The issue is a bug, or the PR is fixing a bug label Oct 9, 2020
@joerchan
Copy link
Contributor

@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.

@laxiLang
Copy link
Contributor Author

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.

@joerchan
Copy link
Contributor

@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.

@nashif nashif added the priority: medium Medium impact/importance bug label Oct 13, 2020
joerchan added a commit to joerchan/zephyr that referenced this issue Oct 14, 2020
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]>
@joerchan joerchan added priority: low Low impact/importance bug and removed priority: medium Medium impact/importance bug labels Oct 14, 2020
@joerchan
Copy link
Contributor

@nashif I set it to low instead. It's just an inconsistency in the parameters, nothing is missing.

@joerchan joerchan changed the title Zephyr host gatt discover response missing permission value Bluetooth: Host: Inconsistent permission value during discovery procedure Oct 14, 2020
carlescufi pushed a commit that referenced this issue Oct 15, 2020
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants