gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350
Conversation
There was a problem hiding this comment.
I tested the PR using you instructions and adding the prefix works fine :) I noticed, though, that removing the prefix with nib prefix del 7 2001:db8::/32 does not update the RPL root/instance table while the ifconfig gets properly updated. Is this something that should also be considered in this PR?
Does removing the prefix remove the address, too? If so, it should be updated as it would be when removing the address (best via the removal of the address), if not, the prefix list should be considered independent of the address list and the behavior is correct. Only question then is how RPL's PIO handles that situation. |
The current behavior can be seen below: The address gets removed from the netif, but the instance table does not change. Is this correct or should the latter be updated as well? |
|
But using |
|
If not, than this is faulty behaviour, which is however unrelated to this PR as this would most likely also be the case in current |
|
So what should I do here - also update |
As already said before: I would prefer to rather hook this up with the address removal rather than the prefix removal (which in turn calls address removal anyway), as the RPL network is defined by its DODAG ID (of type IPv6 address, not IPv6 prefix). That said, since I imagine that this would also require some clean-up on the RPL handler's part, I think it is best to do this in a separate PR. |
(this also makes the current behavior somewhat of a bug btw, since I don't think it is defined how a RPL network should operate with its DODAG ID address not assigned to an interface of the root) |
|
I guess we could merge this PR then, right? (And deal with the prefix/address removal separately.) |
sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c
Outdated
Show resolved
Hide resolved
|
Please try to use the addresses getter provided by NETAPI or the |
|
I don't follow - how is it any more thread safe to do ipv6_addr_t addrs[CONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF];
idx = gnrc_netif_ipv6_add_prefix(netif, &pfx, pfx_len, valid_ltime, pref_ltime);
gnrc_netif_ipv6_addrs_get(netif, addrs, CONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF);
gnrc_rpl_configure_root(netif, &addrs[idx]);How would an address that was just added be subject to change anyway? (And then we would actually want the current version of the address for the RPL root) If the address changes |
|
ping @miri64 😉 |
Fine, but then put at least a |
|
Ok, added - I had to slightly modify |
|
ping @miri64 😉 |
sys/net/gnrc/routing/rpl/gnrc_rpl.c
Outdated
| /* only run RPL on wireless interfaces */ | ||
| if (gnrc_netapi_get(netif->pid, NETOPT_IS_WIRED, 0, NULL, 0) == 1) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Mh... I know defacto it doesn't make sense to run RPL over a wired network, but e.g. for virtualization this might still be important (e.g. many testings of RPL were done with DESVirt on native' TAP if I remember correctly). Does it maybe make more sense to make this dependent on other factors e.g. if a the given OFs can be calculated?
There was a problem hiding this comment.
many testings of RPL were done with DESVirt on
nativeTAP if I remember correctly
Doesn't it make much more sense to use ZEP for that?
Actually this whole PR only exists to enable testing of RPL on CI using ZEP - #17353
Does it maybe make more sense to make this dependent on other factors e.g. if a the given OFs can be calculated?
But OF0 can always be calculated.
If we want a TAP interface to simulate a wireless link, we should rather unset the NETOPT_IS_WIRED property there.
There was a problem hiding this comment.
Actually this whole PR only exists to enable testing of RPL on CI using ZEP - #17353
I am not really clear, how this would help.
There was a problem hiding this comment.
The idea is that adding a prefix via nib prefix add should behave the same as adding a prefix via router advertisement or adding a prefix via UHCP / DHCPv6.
Those will also init RPL on those interfaces, but when adding this I thought it would make sense no to do so for wired interfaces.
I can drop that commit if you prefer that.
There was a problem hiding this comment.
The idea is that adding a prefix via
nib prefix addshould behave the same as adding a prefix via router advertisement or adding a prefix via UHCP / DHCPv6.Those will also init RPL on those interfaces, but when adding this I thought it would make sense no to do so for wired interfaces.
Mh maybe then rather nib prefix add and rpl root should remain separate commands and not everything should be automated ;-).
There was a problem hiding this comment.
There is now #17709
There was a problem hiding this comment.
I have no experience with RPL, but quickly searching for wireless in RFC65550 shows to me that it is not strictly restricted to wireless interfaces.
1.2. Expectations of Link-Layer Type
In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link-layer technology. RPL
is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low-power wireless or PLC
(Power Line Communication) technologies.
|
The more I think of it and with the discussion unfolding in #17350 (review), I am getting more and more the feeling, that |
|
I still would like to have fd660ec in - I think I just forgot that in the initial PR and it should behave the same as UHCP and DHCPv6. I can drop 19c675e.
This is easy to get wrong. |
I am not against that. I just think there might be harm in having too much bootstrapping in |
5e0cc46 to
3938375
Compare
3938375 to
14d5681
Compare
sys/net/gnrc/routing/rpl/gnrc_rpl.c
Outdated
| /* only run RPL on wireless interfaces */ | ||
| if (gnrc_netapi_get(netif->pid, NETOPT_IS_WIRED, 0, NULL, 0) == 1) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
I have no experience with RPL, but quickly searching for wireless in RFC65550 shows to me that it is not strictly restricted to wireless interfaces.
1.2. Expectations of Link-Layer Type
In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link-layer technology. RPL
is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low-power wireless or PLC
(Power Line Communication) technologies.
|
I guess if RPL works across multiple interfaces that would make sense? |
4771bd3 to
2add3dd
Compare
|
Would it make sense to only enable RPL for 6Lo interfaces instead? |
No. RPL is not bound to 6LoWPAN, but can be used with any mesh network technology. |
|
Fine, then let's just drop 8ec0d7b |
2add3dd to
5785856
Compare
sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Call sequence is as in dhcpv6 and uhcpc and initialization works.
> 2022-05-02 19:10:07,389 # ifconfig
2022-05-02 19:10:07,395 # Iface 6 HWaddr: 00:00 Channel: 26 Page: 0 NID: 0x23 PHY: O-QPSK
2022-05-02 19:10:07,396 #
2022-05-02 19:10:07,401 # Long HWaddr: 4E:49:6F:54:4F:76:00:00
2022-05-02 19:10:07,407 # TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4
2022-05-02 19:10:07,414 # AUTOACK ACK_REQ CSMA L2-PDU:102 MTU:1280 HL:64 RTR
2022-05-02 19:10:07,417 # RTR_ADV 6LO IPHC
2022-05-02 19:10:07,420 # Source address length: 8
2022-05-02 19:10:07,422 # Link type: wireless
2022-05-02 19:10:07,428 # inet6 addr: fe80::4c49:6f54:4f76:0 scope: link VAL
2022-05-02 19:10:07,434 # inet6 addr: fd00:a:a:8000:4c49:6f54:4f76:0 scope: global VAL
2022-05-02 19:10:07,437 # inet6 group: ff02::2
2022-05-02 19:10:07,439 # inet6 group: ff02::1
2022-05-02 19:10:07,443 # inet6 group: ff02::1:ff76:0
2022-05-02 19:10:07,446 # inet6 group: ff02::1a
2022-05-02 19:10:07,447 #
2022-05-02 19:10:07,451 # Iface 5 HWaddr: 4E:49:6F:54:00:00 Link: up
2022-05-02 19:10:07,459 # L2-PDU:1500 MTU:1500 HL:64 RTR
2022-05-02 19:10:07,461 # Source address length: 6
2022-05-02 19:10:07,463 # Link type: wired
2022-05-02 19:10:07,466 # inet6 addr: fe80::4c49:6fff:fe54:0 scope: link VAL
2022-05-02 19:10:07,473 # inet6 addr: fd00:a:a:0:4c49:6fff:fe54:0 scope: global VAL
2022-05-02 19:10:07,475 # inet6 group: ff02::2
2022-05-02 19:10:07,477 # inet6 group: ff02::1
2022-05-02 19:10:07,481 # inet6 group: ff02::1:ff54:0
2022-05-02 19:10:07,482 #
> rpl
2022-05-02 19:10:11,976 # rpl
2022-05-02 19:10:11,977 # instance table: [X]
2022-05-02 19:10:11,980 # parent table: [ ] [ ] [ ]
2022-05-02 19:10:11,980 #
2022-05-02 19:10:11,986 # instance [0 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
2022-05-02 19:10:11,994 # dodag [fd00:a:a:8000:4c49:6f54:4f76:0 | R: 256 | OP: Router | PIO: on | TR(I=[8,20], k=10, c=0)]
ACK.
|
Thank you for the review! |
Contribution description
Currently there is no way to initialize a RPL root from the shell in the same way as with automatic prefix configuration.
This changes the
nib prefix addcommand to use the same mechanism asuhcpcanddhcpv6when adding a new prefix.I also added this to the
ipv6_auto_subnetsas this was missing there before.To avoid conflicts with heterogeneous downstream networks (wired and wireless downstream) I added a check to only initialize RPL on a wireless interface.
Testing procedure
Issues/PRs references