-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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: Mesh: Friend node not cache for lpn which receiveing unknown app_idx #24014
Labels
area: Bluetooth Mesh
bug
The issue is a bug, or the PR is fixing a bug
priority: low
Low impact/importance bug
Comments
@jhedberg CC |
@LingaoMeng could you provide the additional details (like a quote of the code) as you did in the original issue? |
if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) { zephyr/subsys/bluetooth/mesh/transport.c Lines 1765 to 1801 in 7ab754d
zephyr/subsys/bluetooth/mesh/transport.c Lines 909 to 913 in 7ab754d
|
trond-snekvik
added a commit
to trond-snekvik/zephyr
that referenced
this issue
May 15, 2020
Ensures that friend messages are enqueued, even if the packet is received with an appkey is unknown to the friend. Previously, sdu_recv would return EINVAL if the appkey was unknown, which would prevent the lower transport layer from adding the packet to the friend queue. This is irrelevant for the logic in lower transport, and should not be returned as an error. Fixes zephyrproject-rtos#24014. Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
carlescufi
pushed a commit
that referenced
this issue
May 15, 2020
Ensures that friend messages are enqueued, even if the packet is received with an appkey is unknown to the friend. Previously, sdu_recv would return EINVAL if the appkey was unknown, which would prevent the lower transport layer from adding the packet to the friend queue. This is irrelevant for the logic in lower transport, and should not be returned as an error. Fixes #24014. Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
krip-tip
pushed a commit
to krip-tip/zephyr-local
that referenced
this issue
May 30, 2020
Ensures that friend messages are enqueued, even if the packet is received with an appkey is unknown to the friend. Previously, sdu_recv would return EINVAL if the appkey was unknown, which would prevent the lower transport layer from adding the packet to the friend queue. This is irrelevant for the logic in lower transport, and should not be returned as an error. Fixes zephyrproject-rtos#24014. Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area: Bluetooth Mesh
bug
The issue is a bug, or the PR is fixing a bug
priority: low
Low impact/importance bug
When friend node use a different application key with lpn node, the friend not cache them.
But, the spec not limited for this.
The text was updated successfully, but these errors were encountered: