Skip to content

Conversation

@elenaf9
Copy link
Contributor

@elenaf9 elenaf9 commented Jul 8, 2025

Contribution description

Opening this as draft to get some early feedback.

Use the information about closed connections in nimble/rpble to mark a parent as unreachable in RPL.

See self-review for discussion points.

Testing procedure

Tested on IOT-testbed with 1 root and 5 other nodes -> when connection to parent closes RPL parent timeout is triggered as expected.

Issues/PRs references

Part of #21574.
Depends on #21585.

elenaf9 added 4 commits July 8, 2025 18:28
Iterate through all parents whose address match `addr`.
In most cases there will only be a single parent, but if
`GNRC_RPL_INSTANCES_NUMOF > 1` then one node can be parent in multiple
DODAGs.
Add new message type `GNRC_RPL_MSG_TYPE_ADDR_UNREACHABLE` to inform RPL
thread of an unreachable IPv6 address.
RPL will then iterate through its parents and timeout the parents with
matching address.
Inform RPL that an address is unreachable if the BLE connection to the
RPL parent breaks.
@github-actions github-actions bot added Area: network Area: Networking Area: pkg Area: External package ports Area: BLE Area: Bluetooth Low Energy support Area: sys Area: System labels Jul 8, 2025
uint8_t version; /**< DODAG version */
uint8_t role; /**< RPL role of the node */
uint16_t rank; /**< the node's rank in the DODAG */
ipv6_addr_t parent_addr; /**< address of the node's preferred parent */
Copy link
Contributor Author

@elenaf9 elenaf9 Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to know the ipv6 address of the parent because RPL doesn't know anything about L2 addresses..

Storing it in the local rpl context is (for now) the easiest solution, but alternatively we could also build it directly from the l2 address or use the neighbor cache (which would require #21580).

#include "thread.h"
#include "nimble_riot.h"

#include "net/ipv6/addr.h"
Copy link
Contributor Author

@elenaf9 elenaf9 Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import needed here because the {nimble/}host/* imports below have some definitions that conflict with the byteorder.h that net/ipv6/addr.h imports.

Comment on lines +182 to +184
msg.type = GNRC_RPL_MSG_TYPE_ADDR_UNREACHABLE;
msg.content.ptr = addr;
msg_send(&msg, gnrc_rpl_pid);
Copy link
Contributor Author

@elenaf9 elenaf9 Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this cause an issue if it ends-up blocking the caller (in my case the nimble thread)? We need to use IPC because the rpl data structures aren't thread safe.

Comment on lines +132 to +143
/**
* @brief Iterate over all parents in all DODAGs with IPv6 address @p addr.
*
* @param[in] idx Index to start searching from.
* @param[in] addr IPV6 address of the parent.
* @param[out] parent Pointer to the parent if one was found. Otherwise NULL.
*
* @return Index > 0 to continue next search from, if parent was found.
* @return -ENONENT if not found.
*/
int gnrc_rpl_parent_iter_by_addr(ipv6_addr_t *addr, gnrc_rpl_parent_t **parent, int idx);

Copy link
Contributor Author

@elenaf9 elenaf9 Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is a bit weird, but it is needed because, theoretically, if we have more than one RPL instance, the same node can be present as parent in multiple dodags, and thus appear multiple times in the gnrc_rpl_parents list.
We want to mark the parent as unreachable in all dodags.

@crasbe crasbe added Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Community: help wanted The contributors require help from other members of the community labels Jul 8, 2025
@elenaf9
Copy link
Contributor Author

elenaf9 commented Jul 9, 2025

Update: I am keeping the PR open for now, but I am currently exploring an alternative design that could solve most of the above discussion points and make this PR obsolete.

@elenaf9
Copy link
Contributor Author

elenaf9 commented Jul 17, 2025

Update: I am keeping the PR open for now, but I am currently exploring an alternative design that could solve most of the above discussion points and make this PR obsolete.

New PR: #21608.

@elenaf9 elenaf9 closed this Jul 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: BLE Area: Bluetooth Low Energy support Area: network Area: Networking Area: pkg Area: External package ports Area: sys Area: System Community: help wanted The contributors require help from other members of the community Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants