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: Mesh: Friend node not cache for lpn which receiveing unknown app_idx #24014

Closed
LingaoM opened this issue Apr 2, 2020 · 3 comments · Fixed by #25340
Closed

Bluetooth: Mesh: Friend node not cache for lpn which receiveing unknown app_idx #24014

LingaoM opened this issue Apr 2, 2020 · 3 comments · Fixed by #25340
Assignees
Labels
area: Bluetooth Mesh bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@LingaoM
Copy link
Collaborator

LingaoM commented Apr 2, 2020

When friend node use a different application key with lpn node, the friend not cache them.
But, the spec not limited for this.

@LingaoM LingaoM added the bug The issue is a bug, or the PR is fixing a bug label Apr 2, 2020
@LingaoM
Copy link
Collaborator Author

LingaoM commented Apr 2, 2020

@jhedberg CC

@jhedberg
Copy link
Member

jhedberg commented Apr 2, 2020

@LingaoMeng could you provide the additional details (like a quote of the code) as you did in the original issue?

@LingaoM
Copy link
Collaborator Author

LingaoM commented Apr 5, 2020

if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) { 

err = trans_seg(buf, rx, &pdu_type, &seq_auth, &seg_count);
} else {
seg_count = 1;
err = trans_unseg(buf, rx, &seq_auth);
}
/* Notify LPN state machine so a Friend Poll will be sent. If the
* message was a Friend Update it's possible that a Poll was already
* queued for sending, however that's fine since then the
* bt_mesh_lpn_waiting_update() function will return false:
* we still need to go through the actual sending to the bearer and
* wait for ReceiveDelay before transitioning to WAIT_UPDATE state.
* Another situation where we want to notify the LPN state machine
* is if it's configured to use an automatic Friendship establishment
* timer, in which case we want to reset the timer at this point.
*
*/
if (IS_ENABLED(CONFIG_BT_MESH_LOW_POWER) &&
(bt_mesh_lpn_timer() ||
(bt_mesh_lpn_established() && bt_mesh_lpn_waiting_update()))) {
bt_mesh_lpn_msg_received(rx);
}
net_buf_simple_restore(buf, &state);
if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) {
if (seq_auth == TRANS_SEQ_AUTH_NVAL) {
bt_mesh_friend_enqueue_rx(rx, pdu_type, NULL,
seg_count, buf);
} else {
bt_mesh_friend_enqueue_rx(rx, pdu_type, &seq_auth,
seg_count, buf);
}
}
return err;
}

BT_WARN("No matching AppKey");
return -EINVAL;
}

@carlescufi carlescufi added the priority: low Low impact/importance bug label Apr 7, 2020
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants