gnrc_dhcpv6_client_6lbr: choose downstream if as !upstream#16530
gnrc_dhcpv6_client_6lbr: choose downstream if as !upstream#16530fjmolinas merged 1 commit intoRIOT-OS:masterfrom
Conversation
miri64
left a comment
There was a problem hiding this comment.
Mhh, so the gnrc_dhcpv6_client_6lbr module now serves also non-6LoWPAN interfaces? Wouldn't it make much more sense to provide a new submodule for this?
|
E.g. |
|
I agree with renaming the module, but I wonder if this should not be the default behavior. |
That's not what I mean. The |
|
See e.g. |
|
(maybe there is potential for cross polination between those new modules, e.g. the runner thread most likely will stay the same). |
|
So how about static void _configure_dhcpv6_client(void)
{
gnrc_netif_t *netif = NULL;
gnrc_netif_t *upstream = _find_upstream_netif();
while ((netif = gnrc_netif_iter(netif))) {
if (IS_USED(MODULE_GNRC_DHCPV6_CLIENT_6LBR)
&& !gnrc_netif_is_6lo(netif)) {
continue;
}
if (netif != upstream) {
dhcpv6_client_req_ia_pd(netif->pid, 64U);
}
}
}and renaming |
Mhhh from the naming this might be misleading. The 6LBR sub-module is all but greedy. How about renaming it static void _configure_dhcpv6_client(void)
{
gnrc_netif_t *netif = NULL;
gnrc_netif_t *upstream = (IS_USED(MODULE_GNRC_DHCPV6_CLIENT_GREEDY))
? _find_upstream_netif() : NULL;
while ((netif = gnrc_netif_iter(netif))) {
if (IS_USED(MODULE_GNRC_DHCPV6_CLIENT_6LBR)
&& !gnrc_netif_is_6lo(netif)) {
continue;
}
if (IS_USED(MODULE_GNRC_DHCPV6_CLIENT_GREEDY) &&
(netif == upstream)) {
continue;
}
dhcpv6_client_req_ia_pd(netif->pid, 64U);
}
}and then make both sub-modules |
|
Just wondering, why '64-bit prefix delegation' - it will happily delegate delegate larger prefixes than can be further sub-divided by downstream nodes. |
Because of this line
If we want something more configurable, we could do something like that (maybe with Kconfig) but then again, why not do interface-wise config then (and allow defining the interfaces instead of just taking all) ;-). |
|
Huh interesting, looks like all the servers I tested with ignored that request and handed out a larger prefix. |
Well the idea I had was that maybe having such config convenience modules won't be necessary when real config comes 😉 |
miri64
left a comment
There was a problem hiding this comment.
You forgot to define the greedy sub-module ;-).
miri64
left a comment
There was a problem hiding this comment.
ACK, now that the architectural problems are out of the way, I trust your testing as well :-).
|
Please squash. |
a8d6864 to
056dcd8
Compare
Contribution description
The
gnrc_dhcpv6_client_6lbrcode only considers 6LoWPAN interfaces possible downstream interface candidates.This needlessly excludes the use of DHCPv6 for non-6lo downstream networks.
Chose all non-upstream interfaces as downstream interfaces for DHCPv6 to allow using it together with e.g. SLIP, DOSE or ethos.
Testing procedure
I tested this on
same54-xprowhich has an Ethernet interface that is used as uplink and which has a downlink device connected via SLIP.For this to work with SLIP a second patch is needed to simulate a L2 address that is then used as an IPv6 IID.
I ran this with
examples/gnrc_networkingwith the following modules added:master
No prefix for the non-6lo downstream interface
this PR
The downstream interface gets a prefix
Issues/PRs references